dingdingdang

But then there's this: "When evaluating the complete bun install improvements, it came out speed-wise to about the same as the existing git usage (due to networking being the big bottleneck time-wise despite more cases being slightly faster with ziggit over multiple benchmarks). Except, it's done in 100% zig and those internal improvements pile up as projects consist of more git dependencies. All in all, it seems like a sensible upstream contribution."

Sooo, after burning these 10k+ worth of tokens we find out that it's sensible to use it because the language (zig) feels good as opposed to git itself which now has +20 years of human eval on it. That seems. Well. Yeah...

Yep. that's the route I tried before, no good, maybe it's just that the documentation is past it's sell by date, maybe it's lack of community use.. I'm just not seeing it. Even the article itself describes how to make an exe file... that will then work in Linux? Or is it simply a program that's easier to run on Wine? Loads of text with unclear details throughout it.

With this exact point in mind: I've recently written a pretty straight forward win32 c implementation of a utility with some context dependent window interactions and a tray icon to help monitor and facility reload of config file.

Is there any way I can use the Wine project to facilitate this compiling and running straight under x11/linux environment as a integrated project that doesn't require the end user to fiddle with Wine? I don't mind bundling shared code as needed. Help appreciated, I tried hard and failed at this endeavour priorly.

This point stands to be underlined! Even the least possible friction is more than people at large are willing to deal with, it's only if the system changes are pushed from the top (rumblings in the EU block at the mo) that we'll see casual consumption of Linux in more mainstream context. Having run Linux Mint across a 50+ coworker setting from a sysadmin perspective this is entirely doable, most will not even notice as long as Chrome is in place alongside with something office-like.

How far are we from having ffmpeg make automatic rotoscope versions of our videos?!

It always had worked like that and it has always been a 100% nonintuitive and peculiar way to deal with this operation

But surely the point is that the proxy key is for your local network, it ain't got no value on the interwebz.

I abandoned MacOS back in 2018 since I found it too quirky and poweruser-unfriendly (the main thing that comes to mind is neatly indicated by todays other MacOS related frontpage article on resizing). Now we can add overt instability to the list.

Confusing mg and IU units up front really do NOT inspire confidence on the topic and conclusion as a whole.

I use another distro but totally appreciate the effort to keep different branches of potential futures alive. Humans have a tendency, in tech and most other domains afaict, to put a lot of eggs in one basket because it's easier/allows-faster-moving-forward.. but that basket may have structural weaknesses that only shows once it has A LOT of eggs in it.

Never read the Foundation series, the concept of psychohistory makes me want to though!

The title actually cringes me out a bit, it reads like early report titles in academia where young students (myself no doubt incl back when) try their hardest at making a title sound clever but in actuality only achieve obscuration of their own material.

Yeah.. this is exactly the overall reality of the ecosystem isn't it? That being said I do hope uv succeeds in their unification effort, there's nothing worse than relying on a smattering of diff package managers and built streams to get basic stuff working. It's like a messy workshop, it works but there's a implicit cost in terms of the lack of clarity and focus for the user. It's a cost I'm not willingly paying.

Talking about Python "somewhere in the middle" - I had a demo of a simple webview gtk app I wanted to run on vanilla Debian setup last night.. so I did the canonical-thing-of-the-month and used uv to instantiate a venv and pull the dependencies. Then attempted to run the code.. mayhem. Errors indicating that the right things were in place but that the code still couldn't run (?) and finally Python Core Dumped.. OK. This is (in some shape or form) what happens every single time I give Python a fresh go for an idea. Eventually Golang is more verbose (and I don't particularly like the mod.go system either) but once things compile.. they run. They don't attempt running or require xyz OS specific hack.

Yup, but 5 to 15% faster year on year is real progress and that's ultimately what the big user base of Python are counting on at this point.. and they seem to be getting it! Full disclaimer: I'm not a heavy Python user exactly due to the performance and build/distribution situation - it's just sad from a user-end perspective (I'm not addressing centralised web deployment here but rather decentralised distribution which I ultimately find more "real" and rewarding).

Anything out there for reference or would you be implementing from theory/ideas here? God speed to you in terms of the project overall, it's exciting to see the beginnings of a rust-like-lang without the headaches!

Any tentative ideas yet as to how you will manage the memory management? Sounds like a sort of magic 3rd way might be in the making/baking!

Yeah: thanks, that's a clear patent on not having me as a customer then

Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!

And I bet even more have downloaded Linux Mint tbh!

Or simply.. drumroll.. THE STATE

Use the Brave browser and look at the inbuilt filtering (search for "Content Filters" in settings), it allows explicit removal of shorts via enabling of "YouTube Anti-Shorts" filter list. Does the job beautifully.

... but we will know from this link, thanks!

edit: to think that such short-form drivel is locked behind a paywall is just sad.

... we'll never know from this paywalled article

Basic-to-great rationality or skill may not be what is being rewarded here (although the baseline of course needs to be met) - it could well be compliance capability. Hence the string of arbitrary memorization exercises.

I don't know, does Cursor offer anything substantial beyond an extension like kilocode? (I've only used vanilla VSCodium branch with various extensions but they all seem to integrate everything from tab-completion to complete UI agentic take-over very well)

Once the UI soup around AI dev use has settled (and it's getting closer) I bet you we will see native apps with c/c++/zig/rust backends that render so much faster on all the junctions that aren't roundtrip limited (and yes, that will still matter to many people).

1. There was no point, having thought about it a bit; a lot of the patches (in essence it was at most a handful) revolved around disabling features which in turn could never have been upstreamed. An example was, as mentioned elsewhere in this comment section, the abysmal performance of the thumbnail gen feature, it never cached right, it never worked right and even when it did it would absolutely kill listings of larger folders of media - this was basically hacked out and partially replaced with much simpler gen on images alone, suddenly the file manager worked again for clients.

2. Guess that's debatable, or maybe even skill dependent (mea culpa), and also largely a question of how comfortable one is with systems that cannot be reasoned about cleanly (similar to TFA I just could not stand the bloat, it made me feel more than mildly unwell working with it). Eventually it was GDPR reqs that drove us towards the big G across multiple domains.

On another note it strikes me how the attempts at re-gen'ing folder listings online really is Sisyphus work, there should be a clean way to enfold multiuser/access-tokens into the filesystems of phones/PCs/etc. The closest pseudo example at the moment I guess is classic Google Drive but of course it would need gating and security on the OS side of things that works to a standard across multiple ecosystems (Apple, MS, Android, iPhone, Linux etc.) ... yeeeeah, better keep polishing that HTML ball of spaghetti I guess ;)

Having at some point maintained a soft fork / patch-set for Nextcloud.. yes, there is so much performance left on the table. With a few basic patches the file manager, for example, sped up by magnitudes in terms of render speed.

The issue remains that the core itself feels like layers upon layers of encrusted code that instead of being fixed have just had another layer added ... "something fundamental wrong? Just add Redis as a dependency. Does it help? Unsure. Let's add something else. Don't like having the config in a db? Let's move some of it to ini files (or vice versa)..etc..etc." it feels like that's the cycle and it ain't pretty and I don't trust the result at all. Eventually abandoned the project.

Edit: at some point I reckon some part of the ecosystem recognised some of these issues and hence Owncloud remade a large part of the fundamentals in Golang. It remains unknown to me whether this sorted things or not. All of these projects feel like they suffer badly from "overbuild".

Edit-edit: another layer to add to the mix is that the "overbuild" situation is probably largely what allows the hosting economy around these open source solutions to thrive since Nextcloud and co. are so over-engineered and badly documented that they -require- a dedicated sys-admin team to run well.

Wonder how these play out against the https://github.com/X11Libre/xserver base, would be interesting to hear from that end as to how these things are handled. My understanding is that they address any sec issues that arise on x.org but it would be fascinating if the issues are already mitigated since XLibre updated their xserver port with 1000s of issues that were never addressed on the x.org side of things.