- We get the window management APIs back perhaps, unlike the eternally broken Wayland ecosystem.
- Yeah, we should introduce competition. It doesn’t feel like Wayland is improving these days. Missing features force me to hit X11 regularly, and I still get Wayland session crashes etc, while X11 could happily run over a year without crash and run all applications I need without issues.
- As others have already mentioned, the continuous multi-monitor(Xinerama) was an afterthought. A good news is that, by design, it’s actually pretty easy to add in the later steps.
- It’s possible that most of old X11 toys would not work properly, because many of them rely on X11 drawing APIs, but they are pretty simple to implement anyway.
- The *original* X11 should die, but the modern Linux GUI stack has long abandoned most of its features anyway. X11 was already reduced to a bit-blitter protocol long before Wayland.
So, in theory, we can embrace a rather-minimal X11 implementation that can run the modern UI, including some desktop features missing in Wayland.
- I'm pretty sure that the peak b/w 2020 and 2023 was a temporary boost induced by COVID-19.
- It’s a shame. I’m really enjoying their SATA 8TB QLC SSDs in RAID0 for mostly read-only data. It seems like I cannot scale my system vertically in the same manner. :/
- An interesting story, a tech post with a rich intimate personal story, I enjoyed it pretty much.
But, in my first attempt to read it, I got totally lost in the very first part. I had to go back and forth to understand where it was coming from and where it is heading. I think a little bit of guidance at the beginning would not hurt, for example something like: “this is my personal journey related to the design of an app,” maybe in light gray and italic.
- Everyone talks about txt files and editors etc, but my main driver is actually paper.
Every morning I pickup a sheet of used paper, and on the backside of it I hand-copy unfinished todos from the previous day. I write down every important details from that day on that paper. At the end of the day, it goes into a file folder for future references.
Actually I got this habit while working in the military, where I received a 1-page-long daily status report every morning. I used that to keep track of both organization status and my daily tasks. I did use this log to analyze, design and optimize procedures, one of which involved over 100 tasks.
Searching over this record can be problematic, but most of the time I have auxiliary records like email, message, call history, etc, which can help me with tracking down “when” things happened. It’s not much different from digging into system log.
However, I think, with the rise of LLMs, perhaps it’s about time to migrate to txt finally.
- Recently, I used LLMs to draft an intermediate report on my progress. Alongside some details on the current limitations, I also provided comments from the review team (e.g. “it’s fine to be incomplete”, “I expect certain sections” etc) to provide context. Surprisingly LLMs, all of them, suggested me to lie about the limitation and re-frame them as deliberate features, even though I emphasized that the limitations are totally okay. I suspect that mentioning some high profile people in the review team pressured LLMs to derail in the hopes of saving me. While I’ve never been a big fan of LLMs, I definitely lost a big chunk of my remaining faith in this technology.
- Yeah, I really get that. I’ve been a fan of zig and bun since their inception, but, AI corp deep in the dev chain? I feel uncomfortable, because no one knows when they’ll start steering things into weird directions.
- AFACT, the only practically critical issue of colored function is the duplication of code b/w sync and async code paths. Zig avoids this with dependency injection, and that’s enough for practical usages (which basically means “ergonomic”). Other points raised by the original article (like calling async function is more difficult) are pretty much unavoidable for the sake of precise control.
- I really wish something like Mathematica is available in open source. It is a notebook environment based on a Lisp-like language.
Its flexibility is beyond imagination. Programs can emit anything from simple numbers/vectors/matrices to medias (image, sound, video, either loaded or generated) to interactive programs, all of which can be embedded into the notebook. You can also manipulate every input and output code blocks programmatically, because it's Lisp, and can even programmatically generate notebooks. It can also do typesetting and generate presentation/PDF/HTML from notebooks.
What people have been doing w/ Markdown and Jupyter in recent years has been available in Mathematica since (at least) 1-2 decades ago. FOSS solutions still fall short, because they rely on static languages (relative to Lisp, of course).
I mean, really, it's a technological marble. It's just that it's barred behind an high price tag and limited to low core counts.
- This. I already seen too many cases of people wiping out their systems while trying to follow invalid advices from ChatGPT.
- That sounds like an amazing sh*t.
- > The companies that win won’t be those with the most or even the best features. AI will democratize those. The winners will be built on a data model that captures something true about their market, which in turn creates compounding advantages competitors can’t replicate.
And that's why I think the future of the software industry is data-driven, and we will end up with another GNU-like movement around free and open data models/schemas. I think we already have a good starting point: Linked Data[1] and schema.org[2]
[1]: https://www.w3.org/wiki/LinkedData
[2]: https://schema.org/
- This pattern isn't new per-se. The industry already went through it when moving from DHTML to XHR, and it was (mostly) abandoned for good reasons. Modern DOM patching techniques gave rise to some newer variations, but they still make the same old trade-offs. They don't really solve engineering issues like tight coupling and brittleness, nor network issues like latency and larger payload volume.
So, to me, this feels more like an effort to offer a more affordable solution (in terms of engineering cost) for small-/mid-sized companies, rather than a push to expand the boundaries of the technology. Not a bad thing, but it's just a bit disappointing to see history kinda looping back on itself.
- FYI, build scripts are completely optional. Zig can build and run individual source code files regardless of build scripts (`build.zig`). You may need to decipher the build script to extract flags, but that's pretty much it. You can integrate Zig into any workflow that accepts GCC and Clang. (Note: `zig` is also a drop-in replacement C compiler[1])
[1]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- It's about 10% increase from M4, which is impressive. But, hey, I don't think I'm not even using 10% of the M4 processing power on my iPad. What's the point?
Apple seriously need to open up development on/for iPadOS, or it'll become something you by every decade or so. Who needs new model if people can't even utilize what they have right now?
I’m quite glad that those talented guys finally escaped from the pit hole of reverse engineering. It maybe fun and interesting, but its future was already capped by Apple. I wish they find another fashion, hopefully something more original and progressive. Stop chasing and push forward.