dmytrish
dmytrish on Hacker News
On the upside, Opencode has finally nudged me to learn sandboxing via bwrap in Linux and sandbox-exec on Mac.
That's what wayland-client does.
There are two kinds of memory leaks: forgotten manual freeing (all references are gone, but allocation is not) and forgetting to get rid of references that keeps an allocation alive. Both are a kind of logical error, but the first is mostly possible in languages with manual memory management. The second one is a universal logical error (only programmer knows which live references are really needed).
You don't need Mythos for that, just open the bun issue tracker and filter for "segmentation fault".
I agree with most of your points, but why would a Wayland compositor need a hypervisor at all?
That does not mean that "things as they are" is "how it's ought to be".
You don't have to love risk to build something you need.
Thanks so much for great work! I hope to finally see VisionFive 2 with enabled GPU acceleration soon.
~/c/t/s/zpdf (main)> zig version
0.15.2
Sky is blue, water is wet, slop does not work.
...and it does not work. I tried it on ~10 random pdfs, including very simple ones (e.g. a hello world from typst), it segfaults on every single one.
+1, SREs can spend months during their onboarding basically reading design docs and getting to know about services in their vicinity.
Short of publicly releasing all internal documentation, there's not much that can make the AWS infrastructure reasonably clear to an outsider. Reading and understanding all of this also would be rather futile without actual access to source code and observability.
Considering that D in "ACID" stands for "durable", it's a pretty sloppy joke.
What's great about its type system? I find it severely limited and not actually useful for conveying and checking invariants.
> pass around the allocator to every function that allocates to the heap.
what prevents a library from taking an allocator, saving it hidden somewhere and using it silently?
So far, most of Zig enthusiasts look to me like people who get sugar rush from writing fast native code and are ignorant (i.e. newcomers to system programming) or arrogant (e.g. long time C programmers stubbornly stuck in their ways) enough to think that memory safety is just a question of not writing stupid bugs. Or luddites that think that programs must always be simple enough to get memory safety right.
Actually, the strong type system is often why people like to write Rust. Because encoding logic invariants in it also helps to prevent logic bugs!
There is a significant crowd of people who don't necessarily love borrow checker, but traits/proper generic types/enums win them over Go/Python. But yes, it takes significant maturity to recognize and know how to use types properly.
Humans still have to state the goal and write a proof of it, but the proof is computer-verified. It's not irrelevant, except in the sense that any two different ways to prove the same statement are equivalently valid proofs.
Yes, in some sense JavaScript is the pinnacle of programming language design: it's so resilient to chaos that even stochastic parrots can write it with some success.
It's like the absolute minimal threshold of demands for sloppy code to work without immediately falling apart.
Linux already has GNOME and KDE as solid mainstream platforms (which is already twice as good as MacOS/Windows), and it also already has Sway, Hyprland, Niri. If an idea is worth implementing, it gets implemented even with Wayland.
There are type hints for function parameters. With some care and guards, Dialyzer can be somewhat helpful.
What actually drove me nuts was absence of guards and meaningful static analysis on return values. Even in my small but nontrivial personal codebase I had to debug mysterious data mismatches after every refactor. I ended up with a monad-like value checking before abandoning Elixir for my compiler.
I don't know where you got this myth from. Extermination of elite VDV units was not just one plane shot down.
There were many russian helicopters successfully landing at Hostomel, the area saw heavy fighting for several days until it was under Ukrainian control.
> The Russian Il-76s carrying reinforcements could not land; they were possibly forced to return to Russia.[35]
https://en.wikipedia.org/wiki/Battle_of_Antonov_Airport
Rumors of an Il-76 downed close to Vasylkiv did not prove to be true:
> Claims have been made that Ukrainian aircraft shot down two Russian Ilyushin Il-76 aircraft transporting assault troops.[33][124][34] However, The Guardian reports "no convincing public evidence has surfaced about the two downed planes, or about a drop of paratroopers in Vasylkiv".[125]
https://en.wikipedia.org/wiki/Northern_front_of_the_Russian_...
Yes, I find it easier to press single quote in vanilla Firefox, start typing the most unique looking part of the link text, see it become green, press Enter to confirm. The link search feature in Firefox is one of the reasons that keep me using it.
I am not sure I understand what you mean in the context of Haskell.
Yes, but even UART could handle some kind of a simple multiplexer protocol with multiple data streams.
It's a bit creepy to refer to people as "things"
Memory is meant to be reused, "64 bit counter will be enough for everybody" is not how systems programming works.
Async might be a wrong abstraction for high-level programming: green threads/goroutines are so much easier to use.
On the other hand, writing a state machine for handling concurrent events/transitions is literally async done manually. libuv, any high-performance network server, UI events handling are all like that.
I agree that doing low-level async right is difficult and might be an impractically long process.
Async is badly needed in systems programming, more so than at the application level: handling events in embedded/low level components is incredibly tedious without it.
`wezterm ssh` uses ssh the way you describe it.
It does not offer persistence by itself, but iirc there are server components in wezterm which might give you reattach able sessions.