Awesome work! I like the idea of being able to quickly make little tools in your IDE.
Coincidentally, lately I have been thinking of making an IDE using something like Theia or CodeMirror but am holding off because of time for my other projects.
This is really cool. Looks like it has a way for me to use my own dynamic linker and glibc version *.
At some point I've got to try this. I think it would be nice to have some tools to turn an existing programs into a zapps (there many such tools for making AppImages today).
> At some point I've got to try this. I think it would be nice to have some tools to turn an existing programs into a zapps (there many such tools for making AppImages today).
Looks like you met the right guy because I have built this tool :)
Allow me to show my project, Appseed (https://nanotimestamps.org/appseed): It's a simple fish script which I had (prototyped with Claude) some 8-10 months ago I guess to solve exactly this.
I have a youtube video in the website and the repository is open source on github too.
So this actually worked fantastic for a lot of different binaries that I tested it on and I had uploaded it on hackernews as well but nobody really responded, perhaps this might change it :p
Now what appseed does is that you can think of it is that it can take a binary and convert it into two folders (one is the dynamic library part) and the other is the binary itself
So you can then use something like tar to package it up and run it anywhere. I can of course create it into a single elf-64 as well but I wanted to make it more flexible so that we can have more dynamic library like or perhaps caching or just some other ideas and this made things simple for me too
Ldshim is really good idea too although I think I am unable to understand it for the time being but I will try to understand it I suppose. I would really appreciate it if you can tell me more about Ldshim! Perhaps take a look at Appseed too and I think that there might be some similarities except I tried to just create a fish script which can just convert any dynamic binary usually into a static one of sorts
I just want more people to take ideas like appseed or zapp's and run with it to make linux's ecosystem better man. Because I just prototyped it with LLM's to see if it was possible or not since I don't have much expertise in the area. So I can only imagine what can be possible if people who have expertise do something about it and this was why I shared it originally/created it I guess.
Let me know if you are interested in discussing anything about appseed. My memory's a little rusty about how it worked but I would love to talk about it if I can be of any help :p
No, in my experimentation I tried to convert OBS into static and it had the issue of it's gui not working. I am not exactly sure what's the reason but maybe you can check out another library like sdl etc. that you mention, I haven't tested out SDL,OpenGL etc's support to be honest but I think that maybe it might not work in the current stage or not (not sure), there is definitely a possibility of making it possible tho because CLI applications work just fine (IO and everything) so I am not really sure what caused my obs studio error but perhaps you can try it and then let me know if you need any help/share the results!
Only if I don't need to do anything beyond the built-in widgets and effects of Win32. If I need to do anything beyond that then I don't see me being more productive than if I were using a mature, well documented and actively maintained application runtime like the Web.
That's not really true. Even in the 90s there were large libraries of 3rd party widgets available for Windows that could be drag-and-dropped into VB, Delphi, and even the Visual C++ UI editor. For tasks running the gamut from 3D graphics to interfacing with custom hardware.
The web was a big step backwards for UI design. It was a 30 year detour whose results still suck compared to pre-web UIs.
I like this idea and know at least a few who would love to use this if you can solve for the:
'unfortunate rough edges that people only tolerate because they use WINE as a last resort'
Whether those rough edges will ever be ironed out is a matter I'll leave to other people. But I love that someone is attempting this just because of the tenacity it shows. This reminds me of projects like asahi and cosmopolitan c.
Now if we're to do something to actually solve for Gnu/Linux Desktops not having a stable ABI I think one solution would be to make a compatibility layer like Wine's but using Ubuntu's ABIs. Then as long as the app runs on supported Ubuntu releases it will run on a system with this layer. I just hope it wouldn't be a buggy mess like flatpak is.
I love vscodium but more and more I worry about how Microsoft is effecting it down stream. To the point where I'm actively looking into making my own editor. I'm putting it off for now but I'll probably start playing around with Theia and Codemirror on the side just in case.
I'd love to move back to it (or rather, use it for dev work beyond opening large log files to search for things), or atleast have it as a backup for vscode's inevitable enshittification.
same boat. I switched to codium mostly out of purity from AI, and I'd really like it to stay that way, while still getting other QoL improvements. I'm pretty concerned that there's not enough to justify the niche, though.
If I have to bet, I will absolutely go for MS enshitifying it beyond reasonable usability, in one way or another, more soon than later.
Making an editor is anice endeavor. But there are plenty of, which are extremely well developed, open source, in many directions, emacs and vim the most prominent. But many others out there.
Emacs and Vim are terminal based though. So nice things like scroll bars, tabs, drag and drop etc. might be available as hacks but will disappoint in the ways in which they fail to work like a actual GUI interface. I'm also not a fan of model text editors.
For open source GUI text editors there sadly aren't many that match the feature and polish of vscode.
While Emacs can run in a terminal, it is more widely used as a GUI application that can render images, PDFs, variable-pitch fonts, handle mouse support (drag-and-drop, menus, scrollbars), and even work on touchscreens such as on Android [1].
You are right that VS Code has a "nicer" out of the box UX (this is subjective of course), but Emacs offers a malleable environment. In VS Code, you are limited to what the APIs the developers decided to expose. If you want a specific behavior that isn't supported, you either fork the editor or create a feature request ticket and wait for someone to prioritize it. In Emacs, because you have full access to the internal runtime, you can implement that feature yourself in a couple of lines of Lisp.
Thanks, it's been so very long since I've tried emacs. I remember I didn't like how it looked. So I used vim instead. (There was no vscode back then.) So I never did give it much of a try.
Emacs might be a solid editor choice but my intuition is that it probably won't be worth it for the same reason LiteXL wasn't for me. If I do work on adding features to my editor I think I'd be more comfortable doing it in js, html and css. And if possible I'd rather start with a base that's mostly where I want it to be. Trying to turn emacs into vscode sounds like way more of a project than turning Theia or CodeMirror into vscode.
Actually there are plenty of packages already which can near Emacs to VSC or Sublime in look and feel, and imho go circles around the 2 in functionality.
I don’t know them, because I do not like VSC and co. I just have a friend, and when I see his Emacs looks like sublime. Is some work to get it to look like that.
My guess is they're vastly underestimating the time and effort that would take, however, I understand the motivation somewhat, as there's no guarantee that whatever alternative to VSCode you settle on won't also eventually go all-in on AI. For example, KDevelop is planning on heavy AI integration soon.
Sure. But why make this a New Year's Resolution instead of a more open ended resolution? Also what make you think Mozilla would tamper with ublock origin?
So basically Linux desktop needs a large company with enough resources and pull to convince OEMs preinstall Linux desktop on their machines? Sure. But what do we actually get as consumers? Some locked down version Linux that still locks you in via applications that only work on it.
No thank you. I'd rather instead of rooting for another big company replace Microsoft we make it illegal for companies do things to lock people in to their products. If you get caught then you lose whatever ip rights you have on that product and it becomes public domain.
I still use vscodium because there are some features that it has not in the Theia IDE (namely inserting links and images in markdown through drag and drop *)
I like the idea of Theia as a platform. Maybe it would be worth it for me to make a Theia based IDE and implement the drag and drop markdown links feature myself? I am worried about the lack of use of the platform by projects though.
Edit: Actually, it does seem to be used by other projects though not very well known ones. So it might not be that bad of an idea to use as the bases for mine.
Edit 2: Then again some language servers and debug adapters don't work fully with Theia **.
I wonder what the psychological effect of having little or no privacy would do to people. Are we all going to be paranoid schizophrenics? How would a world of paranoid schizophrenics work? How insane are world events going to be from that point on?
China is an example of this. Somewhere that, according to the UN's data, executed "undesirable" people with such gusto that it incidentally decreased the organ donor waitlist time so low that it couldn't be explained by any other factor.
"Perfect" security is only attainable with zero dissent, zero individuality, zero privacy, and zero freedom.
Paranoid, maybe. Schizophrenics? No. Firstly, "paranoid schizophrenia" is an outdated diagnosis. Paranoia is a common symptom of schizophrenia, but schizophrenics exhibiting paranoia are not considered to have separate mental illness from those who are not. Secondly, schizophrenia is not caused simply by psychological stress, and is associated with a large cluster of positive and negative symptoms, with paranoia being only one of them.
Go does surprisingly well at keeping GC freezes to a minimal in a way that you're unlikely to notice... C# has gotten a lot better since the core split as well. That said, there's a lot that comes down to how a developer creates a game.
I was added late to a project working on a training simulation engine, similar to games, where each avatar in the game was a separate thread... man, the GC pauses on the server would sometimes freeze for literally 10-15s, and it was not good at all. I refactored it to use an event-loop model and only 2 other threads, which ran much better overall. Even though it wasn't strictly a game itself, the techniques still matter. Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
> C# has gotten a lot better since the core split as well.
It has improved but the majority of games using C# are using Unity which does not use .NET (Core). It uses Mono or IL2CPP specifically with the Boehm GC so it performs significantly worse than .NET and even standalone Mono (SGen GC).
> Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
State machines are not in fashion. Exposed event loops are not in fashion. Most frameworks do their damnedest to hide those components.
As for GC freezes, if you're doing a game like project you can always just allocate a few huge arrays at startup and reuse those with no deallocation/allocation in most garbage collected environments.
It's not what people mean when they say GC though, especially in reference to games, where you care about your peak frame time more than about your average frame time.
Reference counting can also have very bursty performance. Consider what happens when you decrement the last reference to an object which is the sole remaining reference to an entire large tree of other objects. This will trigger a whole cascade of subsequent decrements and deallocations, which can be arbitrarily large.
Of course, you might say, "Well, sure, but your reference counting implementation doesn't need to eagerly deallocate on dereference." That's true! You can write a ref counter that defers some of those deallocations or amortizes them across multiple operations.
And when you do that, now you really do have a garbage collector.
You should watch some of the more recent Gamers Nexus videos... the average frame pacing counts for a lot, and they're making a concerted effort to show this, as it does represent the level of "jank" in games very well.
More broadly than frame pacing, https://www.youtube.com/watch?v=Fj-wZ_KGcsg is a recent example of one of _many_ interviews going back years on why both frame times and frame rates are all flawed for explaining why some games feel smoother/lag more than others (there are GN videos dating back to 2016 on the subject)
I haven't dug deep enough into C# to say this with certainty, but I believe later C# versions allows you to do enough manual allocation to "almost" get around the garbage collector. As well as new calls to try and nudge the GC away from hot paths.
You need to be very disciplined to pull this off, though. LINQ is basically off limits, for example. And of course, Godot's C# is likely much older than these modern techniques to begin with.
That's good to know. So it probably has the capability if you really wanted to dig in.
But that effort on an active engine would quite a long time to comb through. Really comes down to if a highly invested contributor wants to push it through and gets the go ahead.
>The times of pure manual memory management game engines, across all layers of what requires to draw a frame are long gone.
That's what makes me curious about Rust engines like Bevy. Could is truly pull it off and bring back that kind of thought to game development? It's not "pure manual memory management", but the mindset of Rust requires that kind of thinking.
It will definitely be niche for times to come, since most (non-AAA) games simply aren't going to worry about performance. But it might carve a solid community for those concerned with optimization.
Thing is, FPS don't make fun games, what makes games fun is a great design, delivered in a way that overall performance doesn't hinder the experience.
That is why games like Minecraft, Roblox, Celeste, Balantro make it big. None of them would have happened if the creators followed the advice 100% C coding (or C++ for that matter) was the only way, and yet their design is what made them shine.
Celeste isn't a game that would need to worry about performance in 2018. It's 2d sprites with box collisions and relatively minimal particle effects. Your toaster can run Celeste.
But a game like Factorio with heavy simulations and complex interactions and pathing absolutely needs to consider performance to pull off a seemless experience.
Those are the kinds of games I'd hope engines like Bevy could enable farther down the line. Design is still key, but some game types are a larger technical challenge than others.
In my experience, when using Unity, I became acutely aware of creating garbage and how to avoid it. I used to see a lot of object pooling which is basically a makeshift arena allocator.
Coincidentally, lately I have been thinking of making an IDE using something like Theia or CodeMirror but am holding off because of time for my other projects.
reply