Why?
8,813 karma · joined August 13, 2009
Note that this is only the case if you have vsync enabled. Without vsync you will see the action (or some reaction anyway) +2ms later instead of +16.67ms, just not the full frame. This will manifest as screen tearing though if the screen changes are big - though it is up to personal preference if it bothers you or not.
Personally i always disable vsync even my high refresh rate monitor as i like having the fastest feedback possible (i do not even run a desktop compositor because of that) and i do not mind screen tearing (though tearing is much less visible with a high refresh monitor than a 60Hz one).
I have a feeling the people who write these haven't really used LLMs for programming because even just playing around with them will make it obvious that this makes no sense - especially if you try to use something local based that lets you rewrite the discussion at will, including any code the LLM generated. E.g. sometimes when trying to get Devstral make something for me, i let it generate whatever (sometimes buggy/not working) code it comes up with[0] and then i start editing its response to fix the bug so that further instructions are under the assumption it generated the correct code from the get go instead of trying to convince it[0] to fix the code it generated. In such a scenario there is no clear separation between LLM-generated code and manually written code nor any specific "prompt" (unless you count all snapshots of the entire discussion every time one hits the "submit" button as a series of prompts, which technically is what the LLM using as a prompt instead of what the user types, but i doubt this was what the author had in mind).
And all that without taking into account what someone commented in the article about code not even done in a single session but with plans, restarting from scratch, summarizing, etc (and there are tools to automate these too and those can use a variety of prompts by themselves that the end user isn't even aware of).
TBH i think if FSF wants to "consider LLMs" they should begin by gaining some real experience using them first - and bringing people with such experience on board to explain things for them.
[0] i do not like anthropomorphizing LLMs, but i cannot think of another description for that :-P
There was also this[0] video posted recently here of a Turbo Pascal tutorial which has some interesting intro :-)
What i describe is different from what you wrote, which is that Linux is not binary compatible between distros. This is wrong because Linux is binary compatible with other Linux distributions just fine. What is not compatible is using a binary compiled using a newer version of some shared libraries (glibc included but not the only one) on a system that has older versions - but it is fine to use a binary compiled with an older version on a system with newer versions, at least as long as the library developers have not broken their ABI (this is a different topic altogether).
The compatibility is not between different distros but between different versions of the same library and what is imposed by the system (assuming the developers keep their ABIs compatible) is that a binary can use shared libraries of the same or older version as the one it was linked at - or more precisely, it can use shared libraries that expose the same or older versions of the symbols that the binary uses.
Framing this as software not being binary portable between different distros is wildly mischaracterizing the situation. I have compiled a binary that links against X11 and OpenGL on a Slackware VM that works on both my openSUSE Tumbleweed and my friend's Debian system without issues - that is a binary that is binary portable against different distros just fine.
Also if you want to use a compiler more recent than the one available in the distro you'll need to install it yourself, just like under Windows - it is not like Windows comes with a compiler out of the box.
The original point was about the capabilities LLMs themselves since the context was about the technology itself, not what you can do by making them part of a larger system that combines LLMs (perhaps more than one) with other tools.
Depending on the use case and context this distinction may or may not matter, e.g. if you are trying to sell the entire system, it probably is not any more important how the individual parts of the system work than what libraries you used to make the software.
However it can be important in other contexts, like evaluating the abilities of LLMs themselves.
For example i have written a script on my PC that my window manager calls to grab whatever text i have selected on whatever application i'm running and passes it to a program i've written in llama.cpp to load Mistral Small with a prompt that makes it check for spelling and grammar mistakes which in turn produces some script-readable input that another script displays in a window.
This, in a way, is an entire system. This system helps me find grammar and spelling mistakes in the text i have selected when i'm writing documents where i care about finding such mistakes. However it is not Mistral Small that has the functionality of finding grammar and spelling mistakes in my selected text, it only provides the part that does the text checking, the rest is done by other external non-LLM pieces. An LLM cannot intercept keystrokes in my computer, it cannot grab my selected text nor can create a window on my desktop, it doesn't even understand these concepts. In a way this can be thought as a limitation from the perspective of the end result i want, but i work around it with the other software i have attached to it.
Personally i do not see it like that at all as one is referring to LLMs specifically while the other is referring to LLMs plus a bunch of other stuff around them.
It is like person A claiming that GIF files can be used to play Doom deathmatches, person B responding that, no, a GIF file cannot start a Doom deathmatch, it is fundamentally impossible to do so and person A retorting that since the GIF format has a provision for advancing a frame on user input, a GIF viewer can interpret that input as the user wanting to launch Doom in deathmatch mode - ergo, GIF files can be used to play Doom deathmatches.
Linux software is binary portable between distros as long as the binary was compiled using a Glibc version that is either the same or older than the distros you are trying to target. The lack of "portability" is because of symbol versioning so that the library can expose different versions of the same symbol, exactly so that it can preserve backwards compatibility without breaking working programs.
And this is not unique to Glibc, other libraries do the same thing too.
The solution is to build your software in the minimum version of libraries you are supposed to support. Nowadays with docker you can set it up in a matter of minutes (and automate it with a dockerfile) - e.g. you can use -say- Ubuntu 22 to build your program and it'll work in most modern Linux OSes (or at least glibc wont be the problem if it doesn't).
LCL (Lazarus' equivalent of VCL) took another approach where the base stuff are very Windows-y (due to the VCL heritage) but the backends have to essentially implement not only the backend-specific (Gtk, Qt, etc) widget functionality but also a small subset of the Windows API.
While this makes porting harder for the Lazarus developers, it makes it easier to port stuff between OSes and even port stuff from Delphi to Lazarus (some developers can also use both Delphi and Lazarus - e.g. AFAIK Total Commander uses Delphi for the 32bit builds and Lazarus for the 64bit builds).
Well, Turbo C++ (at least the one in the article) does use common conventions but those were conventions of 1992 :-P. So Copy is Ctrl+Ins, Paste is Shift+Ins, save is F2, open is F3, etc. Some stuff are similar to modern editing like Shift+motion to select, F1 for help, F10 to activate the menu bar, etc. And all shortcut keys are displayed on the menu bar commands so it is easy to learn them (some of the more intricate editor shortcut keys are not displayed in the menus, but are mentioned in the help you get if you press F1 with an editor window active).
Borland C++ had the compiler as part of the IDE (there was also a separate command-line version, but it was also compiled as part of the IDE). This allowed the IDE to not spawn separate processes for each file nor even need to hit the disk - the compiler (which was already in RAM as part of the IDE's process) would read the source code from the editor's buffer (instead of a file, so again, no hitting the disk) and would also keep a bunch of other stuff in memory between builds instead of reading it.
This approach allows the compiler to reuse data not only between builds but also between files of the same build. Meanwhile make is just a program launcher, the program - the compiler - need to run for each file and load and parse everything it needs to work for every single source file it needs to compile, thus rebuilding and destroying its entire universe for each file separately. There is no reuse here - even when you use precompiled headers to speed up some things (which is something Borland C++ also supported and it did speed up things even more on an already fast system), the compiler still needs to build and destroy that universe.
It is not a coincidence that one of the ways nowadays to speed up compilation of large codebases is unity builds[0] which essentially combine multiple C/C++ files (the files need to be aware of it to avoid one file "polluting" the contents of another) to allow multiple compilation units reuse/share the compilation state (such as common header files) with a single compiler instance. E.g. it is a core feature of FASTbuild[1] which combines distributed builds, caching and unity builds.
Of course Borland C++'s approach wasn't perfect as it had to run with limited memory too (so it still had to hit the disk at some point - note though that the Pascal compilers could do everything in memory, including even the final linking, even the program could remain in memory). Also bugs in the compiler could linger, e.g. i remember having to restart Borland C++ Builder sometimes every few hours of using it because the compiler was confused about something and had cached it in memory between builds. Also Free Pascal's text mode IDE (shown in the article) has the Free Pascal compiler as part of the IDE itself, but in the last release (i think) there is a memory leak and the IDE's use keeps increasing little by little every time you build, which is something that wouldn't matter with a separate program (and most people use FPC as a separate program via Lazarus these days, which is most likely why nobody noticed the leak).
[0] https://i.imgur.com/Qvkt3W0.png
[1] https://www.gnu.org/software/texinfo/manual/texinfo/html_nod...
...and everyone else, including everyone who is also using a GUI on Linux - even if they use the GUI version of Emacs.
Non-commercial users also care about backwards compatibility.
Also FWIW Qt does break backwards compatibility in major versions, though the breakage isn't huge. And regardless of commercial or non-commercial, it is in general a good idea to avoid breaking people's working code.
[0] https://github.com/jordansissel/xdotool
Also it should not be locked to a single online storage provider but use some sort of standardized protocol (or at least some pluggable mechanism) to allow any online storage provider - including using self-hosted options - to work with it.
This is how you make something that works for your users instead of taking advantage of them.
-> https://endof10.org/ (it has a map with people who can help install Linux)
-> https://www.opensuse.org/ (what i'm using on my PCs, works fine for the most part[0])
-> https://www.linuxmint.com/ (people seem to like this)
-> https://bazzite.gg/ (seems to be popular with gamers)
-> https://www.debian.org/ (almost everything is based on this :-P)
[0] for the most part because nothing - not even macOS where Apple controls the entire stack from CPU up to the OS - is without problems. Though i'm doing weird stuff with my PC - on my laptop i just threw it in ~3 years ago and it has been working without issues since then
Free Pascal obviously has all of that stuff too.
Chances are 677,634 of those will be broken next week though :-P
The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees.
I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast.
[0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python
I find it kinda amusing that Free Pascal was Turbo Pascal compatible from 1997 but it only fully implemented a standard Pascal mode (the compiler supports multiple dialects) just ~10 years ago (and still doesn't support the Extended Pascal syntax).
There is a difference between graphics as in rendering (i.e. the technical side, how something gets rendered) and graphics as in aesthetics (i.e. visual styles, presentation, etc).
The latter is important for games because it can be used to evoke some feel to the player (e.g. cartoony Mario games or dreadful Silent Hill games). The former however is not important by itself, its importance only comes as means to achieve the latter. When people handwave away graphics in games they handwave the misplaced focus on graphics-as-in-tech, not on graphics-as-in-aesthetics.
It is because there are way more games that work than games that do not work at all. Also in general the "golden path" is really an all AMD PC (since that is where most of the testing and open development goes).
That said sometimes you may need to tinker/tweak things but this applies to Windows too, hence the existence of pcgamingwiki (which recently has added Linux info, though that is still dwarfed by the Windows info). I've been gaming on Linux for a few years now and was gaming on Windows before that and i do not find Linux any worse at all when it comes to getting stuff working (this was certainly not the case before ~2021 or so though).
Other things however do change. It is pointless to make current decisions on the state of software and drivers from years - let alone decades - ago. Back in the 2000s and early 2010s AMD's OpenGL story on Linux was pathetic, if you really wanted any sort of decent OpenGL on Linux you had to use Nvidia.
Things are very different nowadays and i'm saying that as someone who used to buy Nvidia because of their better OpenGL drivers and especially their Linux support.