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.
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.
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.
I agree on the translation part. Llama 3.1 8B even at 4bit does a great job translating JP to EN as far as I can tell, and is often better than dedicated translation models like Argos in my experience.
I had a underwhelming experience with Llama translation, incompatable to Claude or GPT3.5+ which are very good. Kind of like Google translate but worse. I was using them through Perplexity.
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.
Is it really surprising that we're conservative? Most of what comes out of big tech right now is focused on monetisation and control and when it comes to FOSS a lot of companies are trying to get their IP on the map.
For example Ubuntu is trying very hard to push snaps. In contrast to flatpaks only they can run the store for it so there's clearly a motivation of vendor lock-in.
This kind of thing makes me suspicious and more critical of new tech. I'd first want to see if it offers me any value. In this case I don't see the big benefit even though flatpak doesn't seem to carry the lock-in that snap does. But I like the optimisation of dynamic libraries and the way I can update openssl once and have all the apps patched that use it.
Systemd is a different story. It's open enough but a bit too heavy and complex for my liking. It's not bad though and I use it on some of my boxes. Alpine is working on an alternative based on s6 and I'll probably end up using that when it matures.
Anyway I didn't choose Linux/BSD because I cared about having the same as everyone else :) Being able to deviate from the beaten track is one of the benefits of these. I currently use FreeBSD because it has the least corporate meddling right now.
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.
> The fact that, as i mentioned, it is just a package manager. And a bad one.
If you don’t mind me asking again, why is it bad? Because the rest of your post certainly doesn’t answer that question.
I understood that you don’t personally like that libraries change. Unfortunately, they most definitely do and no, preventing everyone on earth from ever releasing an incompatible library is not a realistic solution.
> I just fucking hate the "ohh, you just don't like change" people.
Well, you definitely are complaining about change a lot in a very impassioned way.
>> I just fucking hate the "ohh, you just don't like change" people.
> Well, you definitely are complaining about change a lot in a very impassioned way.
They are complaining about people who assumed an irrational reason for their opposition to something, while they have a rational one. I find that kind of assumption condescending ("let me, the rational one, explain to you how to get rid of your insecurities so you can appreciate how right I am") and kind of infuriating too.
> I understood that you don’t personally like that libraries change.
If you add breaking changes without maintaining the backward-compatible version for a reasonable amount of time, I'd argue your library isn't fit to be a dependency for anything important. I definitely wouldn't use it.
The Python package ecosystem may be a mess, but I still manage to use dozens of shared packages daily with quite rare breaking changes, even in libraries that see a lot of developments. I would prefer that we focus on improving API stability for shared libraries, instead of giving up and duplicating dependencies everywhere.
My understanding is that, by volume, most people using Linux "in anger" (whose needs mostly dictate the direction of Linux development) aren't the SREs maintaining living systems for years at a time; rather, they're the DevOps people with constant streams of greenfield projects, involving half-baked third-party components, that in turn need all sorts of random bleeding-edge dependencies.
> Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.
A lot of the vocal people who pick linux are people who want complete control over their systems. Things like wayland, systemd, and flatpak take away some of that control.
How so? I feel like this is just unfamiliarity / resistance to learning. It's not like these new tools prevent you from accessing their internals. The internals are all still "right there." They just have internals that have been engineered for efficiency over composability or observability.
For example, journald. People know and understand "rotated-gzipped text .log files in a /var/log directory." People don't know, but more importantly, don't want to learn, this: https://systemd.io/JOURNAL_FILE_FORMAT/. It's a simple format, that makes perfect engineering sense as a format optimized for the goals it's trying to accomplish. But it's not text — not the thing a greybeard sysadmin has spent the last 40 years working with — so it's "hard."
Instead of just learning this format and writing tools to interface with it, people instead think of this data as being impossible to access, somehow "locked away" behind journald / journalctl, as if there were some kind of DRM put into your OS prevent you from accessing your own log data.
As it happens, though, journalctl already builds in support for manipulating this data with POSIXy text-based tools — getting your journal as JSON is one `journalctl -o export` away.
But nobody knows about these features (I only just learned about it now, from the link above!), because nobody talks about these features, because the tooling already solves 99% of the real-world problems people encounter, and so it's very rare to actually need to script against the journal.
And if you are in that 1% use-case, maybe you're e.g. engineering a distributed log-ingest system for efficiency; in which case you wouldn't use `journalctl -o export` anyway, but would rather link to journald's C API to parse the journal directly, because that's what's most efficient, even if it's less convenient/UNIXy.
-----
This is similar to e.g. how people pushed back against SPDY/HTTP2.0 for being a "less debuggable" protocol, just because it's binary rather than text-based.
Of course, it's extremely rare that anyone needs to actually debug the transport, rather than debugging their own application-layer protocol they've built on the transport. And because every server and client that speaks HTTP2 still also speaks HTTP1, every application-layer protocol flowing over these links can just be debugged using HTTP1 messages.
But even if you have that 1% use-case where you need to debug the transport, there are simple POSIX-pipeline-y tools to bijectively map the binary wire representation to a text-based one.
But again, when you hit that 1% of use-cases, you're probably a professional doing something weird, such that you probably want to pull out WireShark to analyze the complete nested app-in-HTTP2-in-TLS-in-TCP-in-IP-in-Ethernet packet capture in its original binary form.
And so, even though those bijective HTTP2-to-HTTP1 observability tools do exist, nobody thinks they do, because nobody talks about them, because everybody with the 1% use-case is likely solving a large-scope problem for which the simple UNIXy solution is "underpowered."
And a lot of the complaints about both are very generalized. "Flatpack is bad package management technology" tells you very little about what is wrong with it.
Systemd was such an improvement over the existing speghetti for folks selling / supporting linux that it was a pretty clear takeoff.
Flatpack seems a bit more focused than snaps. The usability issues with snaps kind of surprising given ubuntu has usually had a good user focus. One thing, Fedora has their silverblue / ostree type distribution initiative, which may reduce their use case for using things like flatpack for printer subsystems etc (snaps seem more flexible). I moved off linux desktop a year ago though so not at all current unfortunatly.
Hm, I've some problems with nix and desktop apps that needs opengl or similar machine-specific libraries. There are some hacks, and I also think nix comes very close to a good solution, but it's not 100% yet.
That’s mostly due to video drivers not being under nix’s control deliberately (if packages would depend on them as well, instead of a stub, there would be exponentially more build for each driver). On nixos this is solved by a specifically-placed stub, while it will be distro specific elsewhere, so it may not work for a random distro (that’s where “hacks” come into the picture, choosing a non-nixos distro specific lib as the stub and it will work just fine)
How so? Double-clicking an AppImage from a specific folder is not user-hostile (that's a common pattern across desktop systems), and the blogpost specifically points to appimaged and AppImageLauncher as solutions for full desktop integration.
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.
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.
Nix seems to be the only approach that has a chance, but having good fundamentals isn’t enough. The effort to improve the UX and usability is underway. I’m working on it; are there use-cases or “blow your socks off” demos that would be compelling to help convince developers and application writers?
It looks like that problem is fixed with Flatpak override and not installing the Flatpak with root?
This is also probably because the Signal Flatpak is community developed on Flathub from Signal's .deb, they're not building Signal with Flatpak in mind. Mozilla provides an official Flatpak release of Firefox.
I'm sure official Flatpaks do better on average, but that narrows the selection a lot. And most third-party packagers raise my suspicions in a way that, say, the Debian packaging team does not. You should see my eyebrows go up when I cruise dockerhub!
I don't know what the right answer here is, but for me it's not Flatpaks or Snaps. Trusting the packager (and the org behind the package system) is a huge part of it. I breathe a sigh of relief every time I see the software I need is in Debian's repos, even if that means they may not be optimally sandboxed.
FWIW, PhotoStructure has an AppImage edition and it can upgrade automatically in-place.
(There's also a docker image, a macOS DMG, a Windows installer, and other editions as well--and yes, you can configure any edition to _not_ upgrade automatically if you prefer).
It _should_ work just fine. I have several Fedora users (because they emailed me, not because of any analytics: nothing "phones home" with usage, but I do use Sentry for error reporting, and that can be disabled).
If you see any errors, please email me (support@photostructure), post to the forum, or ping me on discord (links to those are in the footer of every page on photostructure.com).
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.
Thief the dark project supports HRTF through OpenAL Soft[0].
Head related transfer function is the.. modeling of how sound waves bounce of your body (shoulders, ears, breast). And it's a part of how we determine where a sound is coming from. Other part is the timing, as in the difference of phase of sound coming in one and in the other ear. Amplitude(volume) is also a part, probably, but we are much more sensitive to difference in phase then amplitude.
If you want to start researching in these things; the start is probably "impulse response" as well as.. a lot really (systems and signals is a heavy book that i should read one day). Just remember that everything is a spring.
As for practical modeling in 3D games and such. The problem is almost the same as global illumination. You would need to model the whole environment and how it responds to sound (absorption, reflection, idk probably even the speed of sound in various materials to be accurate). A great youtube person has a couple videos on whitepapers about this [1-2](the 2 is more practical). Valve bought a company that played with these things, but idk if anything came out of it (iirc it is part of the steam framework now).
I began to write an acerbic comment at "everything is a spring". I then thought about it, and realised you're so right. Linear algebra is crazy. Thank you for the insight. (It struck me that all of quantum mechanics I've ever studied in university was about learning to solve more sophisticated harmonic osciollators.)
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.