Obviously you should set up device mapper to encrypt the gdrive device then put the swap on the encrypted mapper device.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Brian Kernighan - The Elements of Programming Style, 2nd edition, chapter 2

Yeah, some of the world marches slower than other parts.

A major advantage is that this allows us to send proper cache-control headers, with responses to unauthenticated users being cacheable.

Note for people using Cloudflare that it has some pretty dumb caching behaviour so you will want to make sure to disable it for any endpoint that may be authenticated.

I don’t think I wrote down the exact behaviour but IIRC it basically ignores the Vary header. So it will serve the “unauthorized” page to future requests that have credentials. I think it will at least not cache responses with authentication if vary is included but it will cache the unauthenticated ones.

The rant comment will be forever changed.

And dare I say improved.

Have you heard of objective C? It is basically C with embedded Smalltalk.

I don’t know if it is a huge issue but it is definitely a nice to have. There are a few examples I can think of:

1. I open the code in my IDE but build somewhere sandboxed. It would be nice if my IDE didn’t execute the code and can still do complete analysis of the project. This could also be relevant when reviewing code. Often for big changes I will pull it locally so that I can use my IDE navigation to browse it. But I don’t want to run the change until I finish my review as there may be something dangerous there.
2. I am working on a WebAssembly project. The code will never run on my host machine, only in a browser sandbox.
3. I want to do analysis on Rust projects like linting, binary size analysis. I don’t want to actually run the code and want it to be secure.
4. I want to offer a remote builder service.

I’m sure there are more. For me personally it isn’t a huge priority or concern but I would definitely appreciate it. If people are surprised that building a project can compromise their machine than they will likely build things assuming that it won’t. Sure, in an ideal world everyone would do their research but in general the safer things are the better.

That photo seems wrong… BTRFS has a stupid allocator, it always puts data on the disk with the most space in it. So I would expect that to look like

• device 1: A C
• device 2: A C
• device 3: B D
• device 4: B D

Basically chunk A gets allocated and all disks have the same space available, so it gets put onto the first two (I don’t know the exact policy here). Then chunk B gets allocated so it goes on the two empty disks as they have the most space. Then repeat for C and D.

RAID1 with two disks is very simple. It will just put one chunk on each disk, there is no other option. With BTRFS the chunks may not be at the same offset on the disk (like they would with traditional RAID1 or I think ZFS) but one chunk will go on each.

in that is also has some striping functionality.

I think you are thinking about the RAID10 profile which is 2 copies of data striped across the available disks. IIUC RAID10 and RAID1 are identical with 2 disks (as each copy will only have 1 disk available to stripe on which is effectively no striping).

Will this fullfill my two requirements? If not do you have any other recommendations?

Yes, I think it will fulfill your requirements.

Given your setup of 2 disks and 2x replication I would probably go the same route. The other major option is just to use traditional RAID and ext4 (or your favourite other FS) on top.

• Pro: Simpler.
• Pro: More tested stack.
• Con: Less flexible. If you want to add a disk later and benefit from the software raid you will need to do conversions or copies.

Simple, load up the PC speaker driver and play some sound through it.

It’s worth noting that defederation-zero is not a practical requirement. There are some instances that just create loads of accounts and spam communities and reply to comments in communities that you are subscribed to. Of course for most instances they don’t support this and moderator prodding can solve this. But some instances are simply hostile and exist only to spam.

I do agree that I would like my instance to be defederation-minimal. Unless the other instance is being actively harmful or refusing to moderate at all (for example not retaliating for users who are breaking community rules) I would prefer to be able to see their messages and communities. For example I don’t personally agree with blocking Instagram Threads by default. Unless they show complete inability to moderate I would prefer to have the option to subscribe available. Especially because it allows an easy pathway for people to move from Threads to other fediverse instances (although maybe less relevant for Lemmy as it is more discussion oriented rather than personal profile oriented).

I would also like to be able to see per-user instance blocking. This would be a good tool for quick fixes to poorly maintained instances or instances who’s values I don’t agree with without affecting others. It could also serve as a useful signal to the mods. If dozens of people have blocked another instance maybe it is actually quite harmful and should be defederated.

I encourage you to think critically about this and re-evaluate your decision. I would say that for at least 99.99% of people a password manager is significantly more secure overall.

• Browser-integrated password managers will avoid filling your password into the wrong site. This is a great barrier to phishing.
• Allows a unique password per-site which greatly mitigates the problem of password leaks which are fairly common.
• Allows you to use much stronger passwords than you can memorize.
• It’s quite convenient to just click “login”.

For most people phishing is a far bigger risk than some malware stealing their local password databases. To make database theft even less of a concern most password managers have the option to encrypt the local database file. This means that to steal your passwords the malware will need to extract the encryption key from the password manager process which can often be configured to forget the key quickly after the last use.

Also consider that if you have malware that can steal your password database and the encryption key it can probably just keylog all your passwords or steal your browser’s cookie jar. So the extra barrier here is minimal.

I think you are right to be suspicious of having a vault of passwords “ready to steal” but in practice the upsides far outweigh the downsides, especially if you make a security-focused choice of password manager.

That sounds incredibly unlikely. I would be good money that 99% of password length limits are not based on concrete limits. Things like “100 should be enough 🤷” must be way more common.

I doubt 1% of programmers are away of their hashes block size. It is also probably irrelevant since after the first round everything is fixed size anyways.

Drop “memorable”. 99.9% of your passwords should be managed by your password manager and don’t need to be memorized. On one or two passwords that you actually need to type (like your computer login) need to be memorable.

It’s worth noting that crashing is always a browser bug. So while it is likely triggered by a Lemmy bug as well it would be a good idea to report it to the browsers too.

I’ve found that this doesn’t reliably work for kbin communities. But maybe I just had bad luck. I found searching for !functionalprint@kbin.social with “All” (don’t select Communities for what you are searching for) will reliably find communities.

It appears that the URL search may not work for non-lemmy communities like kbin. Searching for !name@server seems to work for all communities.

No, hashing passwords is a different case because you know what the user is so you can use a unique salt. The password itself is also high entropy. For this use cause you can have at best per-post salt.

Think about it. The task that you are asking for is to quickly check if a user has voted for a post to prevent duplicates. So literally the operation you want is the same as you are trying to prevent. If you can enumerate users then you an by definition check if they have voted for a post.

Hashing can’t effectively protect known values. If you want to know if someone voted for a post you can just hash their username and post ID. This is trivial and cheap.

If you want to know who voted on a post you just find every username you can find and hash it. It isn’t super cheap but isn’t very expensive either. There are only 8G people on the planet, many bitcoin rigs can calculate this in seconds. Sure, you can use a more expensive hash and there may be more accounts than people but it will remain feasible.

This is the same reason you can’t hash phone numbers in a meaningful way.

The best option is probably just for the instance to report counts and you just have to trust it. If it is noticed that an instance seems to be inflating votes you stop counting its votes. People can work together to create blocklists for known cheating instances. Your instance would still know this but at least it is within your trust, not federated publicly.

If you add a big delay the botters will just run more requests in parallel. It is a tiny barrier but in a completely different league than even a simple captcha.