In Forth, you can do things like, say, redefine the number 0 to be computed as a function, and all code that uses the number 0 will instantly change its behaviour at runtime.
Why would you do that?
I've never found a legitimate use for it, which is why I hate Forth (and Lisp, for similar reasons).
I like static analysis and I like it when the language prevents me from doing something silly, but I can understand why some people like the elegance and power-rush from one of the god-like languages like Lisp.
TPM's not going to help with that situation, though, right?
Either you're typing in your encryption password on boot (in which case you don't need TPM to keep your password), or you're not, in which case the thief has your TPM module with the password in it.
When I saw the title, I was like "oh, someone's linking to this old thing again".
I'm surprised he keeps it current!
I mean, current-ish.
Glad he found something that works for him.
I would like to hear his thoughts on Forth.
His love of Lisp seems to be from the god-programmer perspective.
Lisp gives you about as much power as you can ask for, for better or worse.
I think Forth goes even a step further, though, letting you redefine constants and things.
BitWarden+PiHole+NextCloud+Wireguard combined will add to like maybe 100MB of RAM or so.
Where it gets tricky, especially with something like NextCloud, is the performance you see from NextCloud will depend tremendously on what kind of hard drives you have and how much of it can be cached by the OS.
If you have 4GB of RAM, then like 3.5GB-ish of that can be used as cache for NextCloud (and whatever else you have that uses considerable storage).
If you have tiny NextCloud storage (like 3.5GB or less), then your OS can keep the entire storage in cache, and you'll see lightning-fast performance.
If you have larger storage (and are actually accessing a lot of different files), then NextCloud will actually have to touch disk, and if you're using a mechanical (spinning rust) hard drive, you will definitely see the 1-second lag here and there for when that happens.
And then if you have something like Immich on top of that....
And then if you have transmission on top of that....
Anything that is using considerable filesystem space will be fighting over your OS's filesystem cache.
So it's impossible to say how much RAM would be enough.
512MB could be more than enough.
1TB could be not enough.
It depends on how you're using it and how tolerant you are of cache misses.
Mostly you won't have to think about CPU.
Most things (like NextCloud) would be using like <0.1% CPU.
But there are some exceptions.
Notably, Wireguard (or anything that requires encryption, like an HTTPS server) will have CPU usage that depends on your throughput.
Wireguard, in particular, has historically been a heavy CPU user once you get up to like 1Gbit/s.
I don't have any recent benchmarks, but if you're expecting to use Wireguard beyond 1Gbit/s, you may need to look at your CPU.
To the best of my knowledge, most of the limitations are around allocation.
NTFS doesn't allow for extent-based allocation, delayed allocation, uninitialized allocation, etc.
It only has one allocation mode, which is the traditional block-at-a-time (actually "cluster"-at-a-time, though NTFS's clusters are roughly block-sized compared to other filesystems), which is now thought to be slightly less than ideal in terms of allocation performance and fragmentation.
And...speaking of fragmentation, I believe NTFS still can't do online defragmentation???
I can't see anything that contradicts this, but it's possible I'm out of date.
There are other small differences.
NTFS has unnecessary filename restrictions, like prohibiting " and ? and things.
But that's typically less important.
It's predominantly the first one.
They have made a few unique design decisions, but is a fairly conservative "boring" RISC design.
The only thing remarkable I can think of of the core ISA is the fact that they have no conditional status registers (no NZVC bits), so you have to kind of combine conditions and branches together, but that's not exactly unprecedented (MIPS did something similar).
In the ISA extensions, there is still some instability and disagreement about the best ISA design for some parts.
Just the fact that RISC-V is going to have both SIMD and Vector instructions is a bit unique, but probably won't make a huge difference.
But it's a fairly boring RISC design which is free and open and without any licensing hoops to jump through, which is the most interesting bit.
Computer-generated (e.g.., Stable Diffusion) child porn is not criminalized in Japan, and so many Japanese Mastodon servers don't remove it
Porn involving real children is removed, but not immediately, as it depends on instance admins to catch it, and they have other things to do. Also, when an account is banned, the Mastodon server software is not sending out a "delete" for all of their posted material (which would signal other instances to delete it)
Problem #2 can hopefully be improved with better tooling.
I don't know what you do about problem #1, though.
The big difference between the WWW and Hyper-G is Hyper-G's distributed link server. This
server keeps track of all the relations (e.g. links) between Hyper-G objects, allowing for automatic
maintenance of the information network. For example, when an object gets deleted, the link server
will be able to find and delete all links pointing to the object. In contrast, in Gopher and WWW
there is no easy way to find out what other documents are pointing to a given document
Dear God that sounds horrible and amazing.
I'm glad it didn't catch on, but I really want to see it in action.
It is hard.
We had Chimera Linux posted here yesterday, which has no GNU code at all.
None of the early Linux distributions had package managers.
The best I can tell, "pms" (package management system) written for Bogus Linux in 1993 was the earliest, but package management didn't hit the mainstream until at least 1995.
Slackware didn't get a package manager until the mid-2000s.
But we still all consider them distributions.
(Right?)
Yes, with some big "if"s.
NextCloud can work very well for a large organization if that large organization has a "real" IT department.
I use "real" to describe how IT departments used to work 20+ years ago, where someone from IT was expected to be on call 24/7, they built and configured their own software, did daily checks and maintenance, etc.
Those sorts of IT departments are rare these days.
But if they have the right personnel, it can definitely be done.
NextCloud can be set up with hot failovers and fancy stuff like that if you know what you're doing.
It is the ticket.
Tickets don't really exist.
Even before the Internet and digital technology, what we called a "ticket" (a slip of paper that you showed to get in) was in reality just a receipt/proof of purchase.
"Ticket" and "receipt" are 100% synonymous.
I expect it to fair much better than Flash.
808/1020 (79%) of the CVEs reported against flash were for memory errors (buffer overruns and things) that allowed remote code execution.
So, assuming the Ruffle developers haven't been using "unsafe", just writing it in Rust immediately removes 80% of the security problems that were with Flash.
Also, many of the security problems with Flash were deliberate (by design).
For example, Flash was designed to send your browser fingerprint to advertising sites.
Ruffle obviously doesn't do that.
That's less fun.
I believe you've either got to put everything on one SLAAC network (no static IPs), or you've got to use DHCPv6 (with a smaller network size) instead of SLAAC.
In Forth, you can do things like, say, redefine the number 0 to be computed as a function, and all code that uses the number 0 will instantly change its behaviour at runtime. Why would you do that? I've never found a legitimate use for it, which is why I hate Forth (and Lisp, for similar reasons). I like static analysis and I like it when the language prevents me from doing something silly, but I can understand why some people like the elegance and power-rush from one of the god-like languages like Lisp.