mioelnir

If as some have commented, parts of the MIT license attribution were removed, Automattic might not have been legally allowed to distribute the software either. At which points the involved lawyers would have a field day trying to figure out how binding a license is that you use for distribution of works that you are not allowed to redistribute.

I've read (once, somewhere, on the internet) that these types of rankings are also distorted by the fact that in the US the top research institutes are usually teaching and part of a University, while they are not teaching in many other parts of the world.

If you have a company car that is free for full personal use, driving around, on holiday etc. then the car is paid for and given to you by your company. Insurance, service and often gas is paid by the company.

On the flipside, 1% of the car's list price as well as 0.03% for every km distance between your residence and place of employment is taxed per month. So for 20km distance, it would be 1.6% of the car's list price. That is added as income onto your monthly salary for tax calculation, and those taxes then deducted from your actual cash salary.

Reminds me of Germany's archive mine https://en.m.wikipedia.org/wiki/Barbarastollen_underground_a...

The english article is not very extensive, but on the german one you'll see at least a few pictures of the storage https://de.m.wikipedia.org/wiki/Barbarastollen

I do not even dislike curl|sh for security reasons. Package managers go to great lengths to provide a reproducible runtime within them. When was the last time you saw 'curl | env -i sh -C' as instruction?

If the script fails halfway? Good look trying to undo whatever it did if you do not have access to `zfs rollback` or similar.

It is also less-than-fun to go through `zfs diff` and the downloaded script to make a package out of it that can be distributed and automated.

> Furthermore salts larger then the final output side offer no additional security. If you have 256bits of output, you only need 256nits of input. Larger inputs technically risk reducing the entropy of the final output.

If I understand that correctly, then for a 256bit hash with an internal state of 1024 bit, initialized to a fixed and public nothing-up-my-sleeve set of values, increasing the salt from 256 bit to 1024 bit - going from 1 random bit for every 4 known bits to 1 for 1 - reduces entropy.

If from there we assume that the hash uses a Merkle-Darmgard block construction for which it is proven that the only loss of entropy comes from the compression function, this would - for me - mean that the chosen compression function loses more entropy on random bits than on the initialization vector, which makes it special, although it is supposedly chosen to be not special in any way.

This confuses me, but I'm just a sysadmin not a cryptographer, so that is ok. Do you have any links for me to follow up on this?

Please note that no company has the right to strip your copyright or license away. But they may chose to extend your software without giving you access to the extension, if that is permitted by the license.

...and I meant BIOS(GPT). Hmpf.

It really depends on the system.

I recently got my hands on a Acer Aspire E-571 (Haswell i3-4030U) and suspend/resume in X with i915kms literally just worked installing FreeBSD 11.0-RC3 from installer and xorg/xdm/openbox from packages, no config file touched (apart from adjusting the keyboard layout and setting the lid_close_state sysctl to S3).

What does not work on it yet is the Elan trackpad, since it is the version that is connected via i2c.

Why would your zpool be in any danger from the upgrade?

If you upgrade via freebsd-update and have renamed your custom kernel (and not named it GENERIC), then freebsd-update will tell you when to build and install a new version of your kernel.

If you kept GENERIC as the name of your custom kernel, which is a really really bad idea, then freebsd-update will probably still replace it with a vanilla kernel, haven't checked that in a while. In that case either rebuild your 10.3 kernel again with a fixed name, or upgrade to 11 from source.

I think that should read that these chipsets were added to iwn, considering iwn has been in since at least 8.0 (going by my very non-scientific manpage search).

Correct, it is full disk encryption instead of dataset encryption.

But on the other hand, if you install 11.0 from installer and chose Auto(ZFS) with EncryptedZFS and MBR(GPT) then you will get a GeliBoot installation. There is no boot pool anymore, instead the early boot stages decrypt the root zpool to load the rest of the boatloader, which then decrypts the pool to load the kernel. With bootloader-selectable boot environments.

No idea about the other things, but the wiki is just an additional git repo that you can check out like any other one.

I would disagree with that. Github shows a lot of the benefits of centralization, where they get network effects from forks and pull requests when these do not have to cross git server boundaries.

Using external services in your build process has little to do with centralization. People that do not realize that having an external dependency in there is bad, will also not realize that having two or more of them is bad. That does not mean that you are not allowed to sync stuff in from github, but your release should be buildable without internet connection from local data.

Annual car taxes in germany have been based on emissions for around two decades already. This is the step after that.

Wasn't the reason that Rome was canceled after two seasons the fact that their entire wood-built set burnt down?

How many more are on this list where it is not differentiated between canceled for ratings vs canceled due to an external event?

They, for example, could have added an adsAllowed flag to the API. If you deselect it, you get a 15min delayed feed. Want the recent one? Show the ads. Even an affiliate program for popular clients, sharing ad revenue with them, is not something I would consider totally unreasonable.

But the reality is, unless somebody from Twitter shows up, we will not know which options they investigated, and why the alternatives could not beat the solution they went with.

Back when communication was still phoneline-connection oriented this was done all the time. You had a contractual quality target of 0.0n% of calls that either aborted or did not connect at all over the yearly average. You then over-provisioned your phone system to hit that target. That could mean adding two additional lines you never need just so new year's eve does not screw you over.

There are mathematical models that describe the probability of a new call coming in at any given time. Add the system in terms of how many connections it can have active and how many it can queue, and you can calculate your required sizing for a given quality level.

As a sidenode, this is also why ISDN flatrates were doomed, because the always-connected nature of them broke the models the system was based on. And why new phone companies renting capacity from established ones could offer cheaper connections, they simply rented at a much higher allowed connection error rate.

Using similar, well, maybe even much easier math, you can calculate that your current system at your desired maximum utilization level allows for 432KiB/s downstream for every customer, but if the overall network is underutilized you can achieve up to the n MiB/s your connection is rated for.

Then you add for example hierarchical traffic shaping where queues are allowed to borrow unused bandwidth from other queues. But it is a huge investment, no doubt.

Also, guaranteed bandwidth is imho not that different from a service level target in Bit. You'll have to refund if you break the SLA, the same as if you break your promise.

Just a couple of weeks ago, I upgraded my home storage system from 9 disks (4x3 raidz) from the same manufacturer with partially consecutive serials.

Now its 18 disks (3x6 raidz2) from 3 different manufacturers and every vdev has 2 of each. And the vdevs are physically evenly spread throughout the case.

I sleep so much better. It was kind of a miracle the first setup survived the 4.5 years it did.

Hate driven development. Once your hate for the current solution's inadequacies pass a threshold, you start implementing the replacement.

While the i915 driver nowadays lives in the Linux source tree, it is still released under a permissive license. Same goes for a lot of drm stuff. I'd assume similar for radeon.

The video streams are delivered from their OpenConnect appliances. The video encoding, their actual website and all the client interaction is run in AWS, active/active in three regions (and multiple availability zones per region).

The AWS part is also very dynamic, at any given time most customers are (unknowingly/behind the scenes) participating in 8-10 beta features.

That said, this is all based on talks and presentations they have given at various conferences in the past. It could be different, especially some AWS parts.

> Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working. But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.

Funny enough, FreeBSD is handling runtime hardware changes neither in its init process or rc scripts. Instead the FreeBSD kernel has a single-reader device event channel, which is read by devd. The submitted events range from ACPI laptop lid close/open, to added usb things or ZFS errors. They are matched against configurable rulesets and their respective actions executed. Loading kernel modules, starting daemons etc. Devd also multiplexes the received events to arbitrary numbers of additional consumers via a number of available sockets in /var/run.

You can argue that the earth is shaped like a torus. I can argue that the moon is violet. That is not the point, and has nothing to do with the merit of the argument.

Setting this aside, all usage hours are not equal. How do you compare an hour of enduser desktop usage on Ubuntu 23.57.something to a usage hour of a commercial NAS storage solution internally based on FreeBSD and ZFS? Do you think the enduser performed comparable product testing cycles?

I've seen ZOL systems where the zpool claimed it was online, but contained no vdevs. `zfs list` had no datasets, but datasets where mounted and trying to read from them got your process stuck in-kernel. It just lost/forgot its devices.

Up until one of the latest releases on every boot you could roll the dice by which name your pool would import the devices. Behaving differently on identical machines and setups. Personally, I am still not trusting that problem to not reappear again.

ZOL is bolted on. With a large nailgun. Simple as that. At times, it feels about as integrated as pjd's original patches distributed on the FreeBSD mailinglists. And since this division is not technical, but legal, based on the license choice made 30 something years ago for Linux with regards to where the code could be exported to and what could be imported into, this situation will not resolve itself.

I am well aware of all of that. But all the zfs send/recv options can by their very definition not have the full disk encryption problem hinted at in the comment I replied to.

Also, if it is easier to take your NAS offline and apart to chuck the disks into your desktop (compared exporting it over the network), then your NAS is too small. What you were looking for is a Laptop.

Which leaves abusing the zpool on a memory stick as data interchange format. Most likely with copies=1, so you have to add some par2 files anyway, at which point you could simply put them on figuratively any other filesystem out there. And encrypt them with gpg/openssl etc. That way I would also not have to run a potentially maliciously crafted filesystem within my kernel.

> Putting an IP address filter on that endpoint is usually enough to stop that.

Why is there even direct external IP connectivity to the realserver, sidestepping the loadbalancer?

Do you create zpools on memory sticks? Or how do you export the pool and move the device with the exported pool on it to your linux desktop?

> Interesting that you had no issues without ECC in the first place. Some ZFS boards are pretty against trying ZFS without.

ZFS without ECC is no better or worse than any other filesystem without ECC, in that silent data corruption is possible. It is for this reason just a lot worse than ZFS with ECC, introducing a fault condition normally not seen on ZFS.

But that fault condition does not go away because you chose to skip ZFS due to no ECC. And you will get a lot of other problems on top that ZFS would have helped against, even without ECC.

Lastly, you'll end up back in the horrible land of static partitioning schemes with questionable tooling. Why suffer through that if you do not have to?

No, datasets do not map to vdevs (mirrors). Since it came up in another comment as well: a dataset is a child object of a pool, but it is also the root-object of a subtree that consumes storage in that pool. To the user this dataset is presented as either a filesystem or a blockdevice to name the two most common options.

Apart from internal accounting things like the spacemap, every consumed storage space in a zpool belongs to a dataset in some way. It might be a data block for a file in that dataset, or it might be an old storage block still referenced by a snapshot of a dataset.

A lot of zfs commands work on datasets (send/receive, snapshot, clone, ...). They are also the point where settings such as compression, deduplication etc can be enabled/disabled as well as traditional filesystem mount options like noatime or noexec.

All the datasets consume storage from the pool, which dynamically stripes over all configured vdevs. If you enable an option for a dataset, you enable it for all storage of that dataset which ends up on all vdevs. You can not delegate a dataset to a specific vdev and then enable some option on that vdev.

Also sorry to everyone who knows enough about ZFS internals to realize that I just took their design, pulled it behind a shed and hit it with a blunt, heavy object.

This is how FreeBSD's GELI (which has authenticated encryption for blockdevices) did it. For every 4k data block it presented up the stack, it consumed 9 512 sectors on disk. Each of them contained 480 bytes, the rest for MAC.

With 4k native drives, this became completely impractical. To keep ratios similar, you would have to present 32k byte devices up the stack, which filesystems have troubles with. Or have 1 MAC sector per data sector or similar, cutting your storage in half.