keeperofdakeys

For anyone wondering "why", this linked article in the source gives some background, https://blog.westerndigital.com/storage-architectures-zettab...

So instead of SMR harddrives and SSDs doing extra work to hide their deficiencies, they're pushing this up into the filesystem. In return you get slightly more storage and slightly faster IO. Perhaps not useful on a desktop, but very useful when dealing with thousands of storage devices in a data centre.

In terms of how it would be exposed to users, this feels very well fitted with object storage. Unlike file-based storage, each object can only be read or replaced. So any partial write relies on the program to read the whole object, then write the updated object.

In general Rust emphasises semantics over implementation side-effects. For example you use a pass-by-value because you're semantically moving ownership of the value to the function, not because the implementation may be faster/slower at the assembly level. Not nailing down the implementation is what allows the compiler to make so many optimisations.

If you need concise pointer control, use the unsafe trapdoor built into rust (like Rust's Vec). If you need very specialised code use assembly, not by abusing language side-effects like Duff's Device. If you need fast number crunching use the specialised library for it, not by writing a magic for loop with just the right amount of statements in it.

I admit that sometimes you need to micro-optimise, but I haven't come across this case much in my Rust code. When I do I usually hinder more then help it.

You should be careful trying to apply these micro benchmarks to modern optimising compiles, behaviour may be different depending on the exact code being compiled. Rust especially has immutability and known types in generics at compile time, so the compiler can do a lot of pointer and inlining magic that C and other languages can't.

In the below example Rust switches to using a pointer when you might think it's doing pass by copy/move. This works because in Rust the moved value can never be referenced after calling the function, so the compiler can just pass a pointer and clean up the value after the function has returned.

https://www.reddit.com/r/rust/comments/3g30fw/how_efficient_...

The functions/symbols being used were __kernel_fpu_{begin,end}. These were designed for use within the kernel, and not for external modules - however external modules used them since there was no other alternative. At some point the kernel announced these were being deprecated, and have now been removed.

Since they weren't designed for external modules, someone submitted a patch to make them exportable. However the patch enforced EXPORT_SYMBOL_GPL, so only modules that report being GPL licensed can use them.

Now ZFS is in a position where it can't use the original kernel symbols since they were removed, but can't use the new ones since they are marked as EXPORT_SYMBOL_GPL.

https://marc.info/?l=linux-kernel&m=154689892914091&w=2

The popular Raspberry Pi platform only started shipping with a 64-bit ARM cpu in 2016, and ARM chipsets with 64-bit support only started appearing around 2012/2013. So I'd expect many new embedded platforms to continue using 32-bit systems well into the next decade.

Thanks, I didn't realise that. I need to do some more reading about the topic.

Cryptography is based on "hard problems", something that is easy to solve one way, but hard the other way. Quantum computers provide algorithms that can severely break some of these (namely RSA with Shor's Algorithm https://en.wikipedia.org/wiki/Shor%27s_algorithm), and speed up all the others (namely Grovers Algorithm https://en.wikipedia.org/wiki/Grover%27s_algorithm). So it's not possible to simply increase bits to ensure algorithms are still secure, but it will work for most of them.

On the bright side there is also a branch of cryptography called post-quantum cryptography, which is a collection of algorithms designed to be more resistant in the face of quantum computers https://en.wikipedia.org/wiki/Post-quantum_cryptography.

When you're deploying multiple APs you also want to turn down the broadcast power on them. If the signal of multiple APs overlap too much, clients won't roam onto the next AP in time.

Also don't be afraid to hire someone to do a wireless survey - or do it yourself. Someone will walk around with a laptop, and try to find wifi blackspots/hotspots, and can recommend adjustments to AP power and/or placement.

It does have an interesting effect though. Apple now have a mandate that apps must work in IPv6 only mode, so they need to be developed and tested for it. This in turn means they need an IPv6 network to test it on, giving enterprise a reason to at least enable it (even if they haven't transitioned any internal services).

WPA3 appears to solve these issues. https://www.mathyvanhoef.com/2018/03/wpa3-technical-details....

A lot of captive portals use HTTP interception/redirection, returning a 30X status instead of the expected 204 status.

I'd be surprised if they didn't have some form of rate limiting. Here are some reasons Google DNS does it https://developers.google.com/speed/public-dns/docs/security....

Be careful with that, Google DNS (as an example) will start ignoring your DNS requests if you go over the rate-limit. Not an issue for home users, but an issue for any sizeable business.

Instead of fetching the secret via a direct HTTP call, the secret is fetched from the DNS server (eg. _acme-challenge.example.com.) - where the DNS server is usually separate from the server getting the cert. This can be done with ACMEv1 for certs, and now is required for the new wildcard certs.

Most clients that support DNS-01 can use nsupdate or APIs of public DNS providers to make this an automated process.

ASN.1 has one of the same problems of XML - the data format is far too strict. Many libraries work by generating new structs/classes from the specification, which is a real problem for an agile workflow. The "struct" type also allows keys of the same name, which means you can't properly represent it in a Json/hashmap/dictionary type. (Not to mention that ASN.1 is just the specification language, there are more then ten ways to actually encode it on the wire. And from personal experience it can also be a pain to work with.)

There are plenty of more modern binary formats that would be a good alternative. CBOR, MessagePack, Protobufs, etc.

It looks like web extensions are coming https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57

The web package definitely originates at the origin, but is it up-to-date? While I assume the web packages have expiry dates that the CDN servers would respect, this doesn't give the full control that Cache-Control headers do.

And in terms of functionality, does the AMP web version have all the functionality of the normal site? Often this is something I see missing on AMP sites. A top-bar gives you the ability to get back to the full site.

Even with these changes the top bar does serve one purpose, it tells the user that "something is different about this page". One thing I fear is visiting a web page, and having no hints that the content wasn't loaded directly from the target website.

I have an older one of these, and you can get full root on them. They are basically stock IIRC, if they aren't they can at least run stock openwrt. By default they have a simplified second web interface, with an "advanced" button that loads the openwrt luci web interface.

If you use `git commit --fixup=<commit>`, then the new commit will be automatically moved, and given the "fixup" action when doing an interactive rebase. (Same for --squash).

This means you only need to match the fixups to commits once, when you're initially creating them.

As a species we're still part of the food chain, we depend upon plants and animals to survive, and we're full of microorganisms. Some of the long lasting consequences of the Chernobyl disaster in this respect are quite worrying - https://www.smithsonianmag.com/science-nature/forests-around....

LineageOS no longer comes with root installed, you have to install an extra zip file while flashing to enable it - https://download.lineageos.org/extras

IIRC some root detection mechanisms still check for an unlocked bootloader.

Due to hardware acceleration, AES based ciphers on a modern computer can blow arcfour and blowfish out of the water.

https://blog.famzah.net/2015/06/26/openssh-ciphers-performan...

Yes, some valid code won't pass the borrow checker. But at the same time, far more invalid code doesn't pass it. Personally I see it as a tool to help me reduce possible runtime errors, and instead have them as compile time errors. This does mean that I often need to design my program around it, but that's try of basically every other language.

The few times I do have an issue I'm usually writing FFI code to interact with C, and I try to minimise that code as much as possible.

Removing the borrow checker would allow you to compile broken code (eg. use after free, data races). However given code that compiles on rustc - passes the borrow checker - you don't need to reverify the borrow checking to get correct code from mrustc.

Rebases and merges don't work well together. By default, git rebase will get rid of merge commits. While there is an option to preserve merges (-p), it can lead to some strange behaviour while doing an interactive rebase - see BUGS section in git-rebase man page for more details.

I'd also argue that merge and rebase represent fundamental differences in what commits mean. The former being commits are history, and the latter being commits are features.

I like most if the new tools, but the 'ss' command produces output that's hard to skim. When outputting to a terminal it tries to justify the columns, hiding some information on the next line. When you pipe it through cat (so it can't detect a tty), the columns don't even line up.

Just because it's lossy doesn't mean it can't sound good, but sure aux and lightning are probably better choices if you're concerned about it sounding good.

The huge audio difference described above is atypical from my experience, so I'd blame the stereo's bluetooth support before bluetooth audio itself.

Bluetooth audio itself uses digital compression to keep the bandwidth low, and has a whole bunch of optional codecs (https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Adv...). Your Kenwood may not support the higher quality codecs, meaning it would sound worse than a comparable headphone jack aux cable.

ZFS is definitely still a thing. With the creation of the OpenZFS project, and the Linux port, the future is looking bright.