LGPL says the user needs to be able to replace the LGPLâed code with their own modified version. You canât do that on an iPhone. I think thatâs the issue there.
Also the SDL devs are themselves game developers/porters (I think that came out of Loki games), so itâs not so hard to understand why they would relicense their stuff, it basically makes their own life easier also.
Itâs so commercial game devs can ship it on iOS and consoles. I think Apple makes it impossible to comply with the LGPL. Probably same thing for Sony, XBox and Nintendo.
Iâm not too mad even though Iâm a GPL fanboy. If it helps SDL adoption among game devs then that will help portability and Linux support in the long run. It will also help games run better on Linux: plenty of games that donât use SDL have annoying issues with my tiling WM for example.
With SDL 2, they even thought about the future compatibility issues due to static linking: Even if a game statically links SDL, you can still override the static copy with your own dynamic library. The static SDL will forward all function calls to the user supplied SDL.
Iâve seen hot takes about this on Reddit where people bring up these points:
- A bunch of volunteer maintainers that neither have the time, motivation or skill to security audit these packages wonât do any good.
- Itâll never work because devs want to go fast and itâs not worth introducing stuff that slows down process by doing any vetting
To the first point I want to look at the evidence, which clearly suggests malware and shit like never make it into any Linux distro. This probably has less to do with security audits and expertise and such, but rather the desire of the packagers to actually package useful and legit software. It acts more like a general heuristic spam filter that throws out sketchy shit as part of the assessment of any software being useful and trustworthy by culturally aware people. These people canât be tricked like a shitty spam filter would.
To the second point I think some bleeding-edgelords undervalue stability and ignore the amount of work this actually causes everyday. Updating too often creates more work in many cases, though updating very rarely clearly also causes problems. Thereâs probably a middle ground here.
Plus this whole argument is arguably kinda tangential to the actual point: There are rolling release distros that are only days or weeks behind upstream, and they still donât suffer that spam problem where random strangers are allowed to basically upload any crapware without human supervision.
First of all, this is probably a bad sign for the health of your drive, you should look at the dmesg output and SMART diagnostics of the drive. Thereâs a package called smartmontools or something like that. Also make a backup now if you havenât yet.
If itâs just the filesystem thatâs borked try fsck like that other person said.
I like Taler, but itâs specifically designed to not give anonymity to sellers. In order to verify that you got a valid token (meaning it was issued by an accredited bank and was not already spent) you need to deposit it with the bank.
Now if you get money from a friend you trust has given you a valid token, then thatâs not an issue. You can just use it to pay for stuff and nobody will know how you got that token. A seller however will want to verify the token immediately or they might end up giving stuff away for free.
I guess for donations it could work since youâre not giving anything in return and so canât be scammed, but itâs obviously a bit of a problem since you could be sitting on worthless tokens. You donât know what funds you have until you try to spend them, and people will probably get pretty annoyed with you if most of your tokens end up being fake. Not sure how one might protect themselves against this sort of spam.
As I said, every file read from disk, be it an executable, image or whatever gets cached in RAM automatically and always.
Having said that, if you read a file using read(2) (or like any API that uses read() internally, which is most), then you end up with two copies of the file in RAM, the version your OS put in the disk cache, and the copy you created in your processâs memory. You can avoid this second copy by using mmap(2). In this case the copy of the file in the disk cache gets mapped into your processâs memory, so the RAM is shared between your copy and the disk cache copy.
You can also give hints to the disk cache subsystem in the kernel using fadvise(2). Donât though unless you know what youâre doing.
This doesnât explain what a disk cache (afaik often refered to as page cache) is, so here goes: When any modern OS reads a file from the disk, it (or the parts of it that are actually read) gets copied to RAM. These âpagesâ only get thrown out (âdroppedâ) when RAM is needed for something else, usually starting with the one that hasnât been accessed for the longest time.
You can see the effect of this by opening a program (or large file), closing it, and opening it again. The second time it will start faster because nothing needs to get read from disk.
Since the pages in RAM are identical to the sectors on disk (unless the file has been modified in RAM by writing to it), they can be dropped immediately and the RAM can be used for something else if needed. The downside being obviously that the dropped file needs to be read again from disk when it is needed the next time.
I like how that material design stuff looks on my Android. Bite me.
To the people complaining they canât figure out what is or isnât a button: How often really does that happen to you? Even the computer illiterate somehow manage on their Androids and websites.
Windows 9x, which gets brought up in these discussions as an example of some sort of perfection, had plenty of âbuttonsâ that had no 3D effect, including menus, icons in icon bars, systray icons and desktop icons. WordPad originally had all the icons up in the icon bar with a 3D effect. It looked like shit and Microsoft stopped doing that in 97 at the latest.
There are considerations other than clarity of intent, like not distracting people from the content with all that ornamentation.
My suggestion would be to put a picture of a baroque church as your background to even out the minimalism if it bothers you so much.
Debian allows setting up disk encryption during install for example. Never heard of VeraCrypt, I donât think thatâs popular on Linux. The relevant under the hood parts if youâre interested in how it works on Linux are:
- dm-crypt: Linux kernel feature for accessing encrypted partitions
- Luks: A header format / standard for encrypted partitions
- cryptsetup: command line tool to set up and manage all this
Unsuccessfully.