just another C hacker- enriquto parentAnd sourcehut in the Netherlands!
- I don't see the difference between "local, open weights" and "local, proprietary weights". Is that just the handful of lines of code that call the inference?
The model itself is just a binary blob, like a compiled program. Either you get its source code (the complete training data) or you don't.
- > why not do it in C?
Well, because you can do it in Fortran, of course!
What else do you want? Multidimensional arrays out of the box, fast loops, native cuda support, trivial build and packaging system, zero version churning... all of this just with the bare language. It's the anti-python! The perfect language, you could say! Strings and i/o are a bit cumbersome, agreed, but your llm can take care of these without any trouble, no matter the language.
- > I am thrown back by how... "janky" the syntax is.
Well if you come from C++ it's a breath of fresh air! Rust is like a "cleaned-up" C++, that does not carry the historical baggage forced by backwards compatibility. It is well-thought out from the start. The syntax may appear a bit too synthetic; but that's just the first day of use. If you use it for a few days, you'll soon find that it's a great, beautiful language!
The main problem with rust is that the community around it has embraced all the toxic traditions of the js/node ecosystem, and then some. Cargo is a terrifying nightmare. If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.
Concerning TFA, adding rust to apt might be a step in the right direction. But it should be symmetric: apt depends on rust, that's great! But all the rust that it depends on needs to be installed by apt, and by apt alone!
- that's great!
The ~/.mozilla folder is one of the last remaining dotfiles in my home directory
You can also be an xdg ninja if you want: https://github.com/b3nj5m1n/xdg-ninja$ ls -a ~ . .. .bashrc .mozilla .profile .ssh bak config local pro srcAnnoyingly, many programs hardcode ~/.config and ~/.local (instead of using XDG_CONFIG_HOME etc) and try to recreate them every time they run. This is a good indication to stop using these careless programs!
- > X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program
This has nothing to do with X11 or even UI at all. You should not run any low-trust program whatsoever (outside of a container). Any program that runs as your user can change your ~/.bashrc or any other file on your homedir.
Of course this is a feature that you want, for example when you edit these files with a text editor.
- > The language itself is awful.
As a programming language freak, I must disagree... in what other programming language can you solve a linear system Ax=b in one line
without any external libraries or imports, just with the base language?x = A\bI never used any official matlab "toolbox", but still love the language via the octave interpreter. It's so clean and straightforward!
- Oh, this is one of my favorite (and sad!) dramas in free software.
Five years later the main llvm developer proposed [0] to integrate it into gcc.
Unfortunately, this critical message was missed by a mail mishap on Stallman's part; and he publicly regretted both his errors (missing the message and not accepting the offer), ten years later [1].
The drama was discussed in realtime here in HN [2].
[0] https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html
[1] https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
- what is the point of this? you can just import inside function definitions:
thus numpy.linalg is only imported the first time you call the antislash function. Much cleaner than a global import.def antislash(A, b): from numpy.linalg import solve return solve(A, b)Ignore wrong traditions. Put all imports in the innermost scopes of your code!
- > Are you allowed to run whatever computer program you want on the hardware you own?
Yes. It is a basic human right.
> This is a question where freedom, practicality, and reality all collide into a mess.
No; it isn't. The answer is clear and not messy. If you are not allowed to run programs of your choice, then it is not your hardware. Practicality and "reality" (whatever that means) are irrelevant issues here.
Maybe you prefer to use hardware that is not yours, but that is a different question.
- The very name "permissive" licenses is problematic, because it steers the discussion towards the point of view of software middlemen, not of users.
From the point of view of a user, a copylefted software allows the user to do more things: the license grants them permission to see and change the source code of the software, no matter how they got it. With so-called permissive software, the user may be stripped of this permission by third parties.
- > I quickly jump to python instead of using Bash even for the simplest of scripts
You don't seem to respect the old, venerable, well-tested adage: "once your shell script becomes too complex, switch to a real programming language like python".
Or, the zen version (formally equivalent, but with quite a different tone): "once your program becomes sufficiently simple, turn it into a beautiful shell script".
- the problem is that there's no reasonable thing to do when the height of the terminal in pixels is not an integer multiple of the height of the font in pixels. Whatever "it" does, will be wrong.
(And when it's an integer multiple, you don't need scaling at all. You just need a font of that exact size.)