gens (u/gens) - Readit News

gens commented on Roc rewrites the compiler in Zig gist.github.com/rtfeldman... · Posted by u/todsacerdoti

pcwalton · 7 months ago

> I was looking for a replacement for C, but Rust is actually a replacement for C++. Totally different beast - powerful but complex.

I've seen this sentiment a lot, and I have to say it's always puzzled me. The difference between Rust and basically any other popular language is that the former has memory safety without GC†. The difference between C++ and C is that the former is a large multi-paradigm language, while the latter is a minimalist language. These are completely different axes.

There is no corresponding popular replacement for C that's more minimalist than Rust and memory safe.

† Reference counting is a form of garbage collection.

gens · 7 months ago

It is not about memory safety or anything like that. It is about simplicity.

If you say "you can't do x with y in C++" you will get an "yes you can, you just use asd::dsadasd::asdadqwreqsdwerig_hfdoigbhiohrf() with weaorgoiawr flag". From what I have seen from Rust, it is similar. I don't want to fill my brain with vim bindings.. cough.. Rust ways of doing something. I just want to code my hobby game engine v7.

That said, I am happy to use software written in it. Even though the evangelists can be really annoying.

gens commented on Hacker plants false memories in ChatGPT to steal user data in perpetuity arstechnica.com/security/... · Posted by u/nobody9999

dcl · a year ago

Llama and its variants are popular for language tasks, https://huggingface.co/meta-llama/Meta-Llama-3.1-8B

However, as far as I can tell, it's never actually clear what the hardware requirements are to get these to run without fussing around. Am I wrong about this?

gens · a year ago

In my experience the hardware requirements are whatever the file size is + a bit more. Cpu works, gpu is a lot faster but needs VRAM.

Was playing with them some more yesterday. Found that the 4bit ("q4") is much worse then q8 or fp16. Llama3.1 8B is ok, internlm2 7B is more precise. And they all hallucinate a lot.

Also found this page, that has some rankings: https://huggingface.co/spaces/open-llm-leaderboard/open_llm_...

In my opinion they are not really useful. Good for translations, to summaries some texts, and.. to ask in case you forgot some things about something. But they lie, so for anything serious you have to do your own research. And absolutely no good for precise or obscure topics.

If someone wants to play there's GPT4All, Msty, LM Studio. You can give them some of your documents to process and use as "knowledge stacks". Msty has web search, GPT4All will get it in some time.

Got more opinions, but this is long enough already.

gens commented on Flatpak Is Not the Future ludocode.com/blog/flatpak... · Posted by u/Thin_icE

ahartmetz · 4 years ago

What do you mean? When I think of "...integrate poorly with desktops", I think of Electron apps. These also have a Flatpak-like distribution (but not security) model. And a "best effort" integration model. Basically, whatever is possible without lifting too much of a finger.

gens · 4 years ago

When i think of "desktop integration", i think about drag and drop not working between `ark` (a QT program) and `thunar` (a GTK program), and i think of folk writing blog posts about window theming. (there's also notifications, icons, etc, blablabla, that keeps getting worse (freedesktop is, that is))

To be honest, i don't care much about how programs look. But i do know many people do care.

gens commented on Flatpak Is Not the Future ludocode.com/blog/flatpak... · Posted by u/Thin_icE

WastingMyTime89 · 4 years ago

You are replying to a comment explaining to you why Flatpak actually works with a dismissive sentence implying it's just a bad technology. Do you have anything substantive justifying your opinion?

From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.

gens · 4 years ago

I never said it doesn't work. And yes, i do have "anything substantive" against it. The fact that, as i mentioned, it is just a package manager. And a bad one.

> From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change.

This is what pisses me off. You, nor anyone else, can tell everyone else what >I< think or feel. It's not fear, nor fear of change, nor any other dumb ass reason people who think like you think it is. I hate it because it's just a package manager. I hate it because, when all the reasons against it are brought up, something nebulous like "security" or something quazi-psychological like "fear of change" are brought up in defense of it.

The real problem with flatpacks is that they don't solve the real problem, and they do it poorly.

Want to solve the problem of your program not running on multiple distros, or not running in 5 years ? Then look at why that is. For example; it's not that the zip file format will change, so why must i recompile my program every time libzip changes ? Or X11 to wayland transition; why does my program have to even care about that when all i want is a window and an opengl context ? (bdw the solution to the latter is SDL2)

Let's look back when flatpack started. Why did it start ? Maybe because GTK3 changed it's API ever so often ?

Linux doesn't have a good GUI toolkit. THAT is the biggest problem here.

I just fucking hate the "ohh, you just don't like change" people. That dismisses all further discussion. That is the real "hate" that people like you blame others of.

gens commented on Flatpak Is Not the Future ludocode.com/blog/flatpak... · Posted by u/Thin_icE

alvarlagerlof · 4 years ago

And AppImage integrates poorly with desktops.

gens · 4 years ago

Desktops integrate poorly with desktops.

gens commented on Flatpak Is Not the Future ludocode.com/blog/flatpak... · Posted by u/Thin_icE

cunidev · 4 years ago

To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux.

While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro.

For example, the Elementary OS "AppCenter" apps are now available in any other distribution, thanks to the Flatpak remote. Testing daily GNOME apps has become as easy as installing their Flatpak reference, and letting them update automatically.

Regarding memory, storage and power consumption:

- The base runtimes (which are the heaviest bit) are downloaded only once per system, e.g., one for the KDE Plasma ecosystem, one for Elementary, and so on. The first app you install will pull them, so I do not see it as much more bloaty than having an enormous bundle of system-wide dependencies (e.g. if you install a KDE app in a primarily GNOME environment) as would happen otherwise.

- Memory and CPU-wise, Flatpaks are very light containers (which do not require loop disks, or anything else) which should have almost no overhead. I never witnessed any loss of performance, at least.

- Bug and crash-wise, I experienced a tremendously stable and "flat" experience on Flatpaks. That is, if there is a bug in one app on one distribution, the bug will exist on all, or vice versa. This is not as common as it should be in containerized app install tools, and makes debugging overall much easier.

The only drawback are updates taking longer than on other platforms, probably because compressed deltas are not yet available unlike in other major package managers.

With this, I don't want to describe Flatpak as a panacea in everything, but at least for GUI apps, it solved a lot of distribution fragmentation issues in my case.

gens · 4 years ago

I recommend just shipping everything you need with your app, either manually or using AppImage.

Flatpack is, more or less, just a bad package management.. technology.

gens commented on How much load can be served from 1m² of sunlight medium.com/@timothy_downs... · Posted by u/forkfork

cogman10 · 4 years ago

Looking at the size of this thing, I sort of doubt it's much more efficient than doing a DC->AC->DC conversion. In fact, I'll betcha that's exactly what's happening inside this beast to both get the right voltages and stabilize them.

gens · 4 years ago

It says 72% efficiency, so over 400W of heat at full load. Inverter to a normal PSU would be about the same, if not worse. It could be that it raises the voltage then drops it back down to 12V, but i'd sooner think it's just cheaper mosfets.

Anyway, these kinds of converters can usually regulate themselves.

gens commented on Writing a Linux-compatible kernel in Rust seiya.me/writing-linux-cl... · Posted by u/signa11

volta83 · 4 years ago

Mostly I/O drivers for network and storage, and let's say "DMA-related" functionality.

Anything more specific than would probably de-anonymize me.

gens · 4 years ago

That's cool. I truly wish you all the best in your future :).

gens commented on Writing a Linux-compatible kernel in Rust seiya.me/writing-linux-cl... · Posted by u/signa11

volta83 · 4 years ago

> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary.

As a Linux kernel developer, I feel like non-kernel developers like yourself telling me which language I should use is definetly overstepping a boundary.

I couldn't care less about what non-kernel-developers think about this issue, but "since you mention this": please do mind your own business.

> Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago?

Because we, as in the actual people that spend their whole day developing the Linux kernel *do not want* to write and maintain Linux kernel code written in these languages.

> The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be".

This is so wrong. We, Linux kernel developers, are already writing drivers and kernel modules in Rust, *because we want to*. We now want to merge this new code so that other devs and users can use it. Most other devs want this too, so now we added Rust support to the Linux tree.

---

It really is that simple. My code, my body, my rules.

I really don't know what's so hard for people to understand here.

gens · 4 years ago

May I ask what you developed in the kernel ?

gens commented on It's weird that most of “Hacker” news is dominated by business news · Posted by u/greendude29

gens · 4 years ago

"Hacker" "News"

(It's a somewhat obscure reference)