Default action when api.authy.com cannot be contacted:
1. Disable two factor authentication until api.authy.com is back
2. Don't allow logins until api.authy.com is back
And this is if you buy new. There's a huge market for used light aircraft out there, as they last for decades. You can buy a nice light airplane for less than 1/3rd of what these guys are charging, and something one could consider entirely decent for less than 1/5th.
I can understand that, but I think the two markets are different enough to be worth pointing out. People who buy used cars are often buying something a few years old. By the time a car is ten years old, it's being traded around for a tiny fraction of its original cost, and maybe even headed off to be junked/recycled. Maintenance costs are starting to skyrocket, and because of all that, people tend to trade up frequently.
A used airplane is probably decades old. It's probably selling for a similar price to what it originally went for when it was new. Maintenance costs are high, but they were high when the thing was new, so that's not particularly remarkable.
I'd wager that the majority of light aircraft flying in the US today would qualify for "antique" license plates if they were cars. It's a substantially different market, where the equipment lasts longer and buying used is much more common.
FreeBSD is (more or less) moving towards pkgng, which has roughly the same goals. I'm not sure what the OpenBSD guys are doing
And yes, it's only for distribution. But if it works well, it's the only thing end users should care about. Though I'm not exactly sure the BSDs have basic end users in the way linux does.
> FreeBSD is (more or less) moving towards pkgng, which has roughly the same goals.
Yeah, but the BSDs always had pkg_add and other pkg_* tools, pkgin is just a nice alternative that works on more than one system... I don't believe it provides any crucial feature that was missing in the pkg_tools.
> And yes, it's only for distribution. But if it works well, it's the only thing end users should care about.
From OpenBSD's FAQ:
The ports tree is meant for advanced users.
Everyone is encouraged to use the pre-compiled binary packages.
Basically, if you're running unmodified OS (i.e. official release) and don't enable any options disabled by default in the ports then you're just wasting CPU power rebuilding stuff that you could easily grab from the nearest mirror.
As far as I can tell, there is no tool in FreeBSD base that provides a simple way to check and update all ports using binaries. FreeBSD's pkg_add only handles direct installs of new packages. Upgrade management, things like "update everything" or "update this package and its dependencies" is usually done through one of the external tools like portmaster, portupgrade, pkg_upgrade, etc. Which interact with the ports tree and pkg_add behind the scenes, but with additional info on dependencies to keep the whole thing sane. They do the job okay, but they all have their quirks.
From its man page, it seems OpenBSD's pkg_add supports updating (and a lot of other things), so I guess they don't have this problem to start with. That's interesting, I wonder why the feature is lacking on the FreeBSD side.
Keep in mind that, with one exception, ZFS is pretty much rock-solid from day one.
Citation needed.
And that article doesn't really address any of the problems that the osnews article brings up, it just tries to sidestep the issue by more or less saying that the same fsck tool that ext uses won't work on ZFS. Great.
ZFS was released in 2005, and appeared in Solaris 10 in 2006. Close enough?
Followed by that was people having issues with data corruption... ZFS is great, but it does break from time to time (whether it is better than other file systems is subjective when you consider the options of restoring it). Low failure rate is, for many, a weak comfort when data is irrecoverable.
More importantly, what's the problem with scrubbing instead of fsck?
Scrubbing repairs data, not broken file systems. Scrubbing is of course great but it isn't the answer for everything.
ZFS has had problems, but all production filesystems have. From a strict standpoint, what the original author wrote about bugs is wrong, but from a practical standpoint I don't think it matters. ZFS has been as solid as any other production filesystem from the beginning -- which is to say that any production filesystem might one day rear up and bite you. It's just the nature of our profession.
That's just my opinion though. :)
Scrubbing repairs data, not broken file systems.
That depends what's broken. ZFS has ditto blocks (multiple copies of the same block) going up the tree; roughly speaking, the higher up you are, the more there are. The tree and metadata has more protection than the data itself.
If, say, all the ditto blocks and all the mirrors are corrupt, reconstructing that is going to be hard. I think a case needs to be made that an fsck tool would do a better job repairing than scrubbing, which is non-obvious to me.
Keep in mind that, with one exception, ZFS is pretty much rock-solid from day one.
When we used it in production about 5 years ago it was not so rock-solid. We had to bring in Sun-Support and went through some nasty downtimes for lengthy resilvering.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Because the problem goes beyond failing to invalidate the existing cache for the resource (which is a SHOULD), Chrome does not even make the request, which most definitely isn't acceptable under any circumstance, even after careful considerations. The spec even emphatically says that responses to a DELETE are not cacheable, how could you use an existing cached response as valid for a DELETE if you are not allowed to cache a delete in the first place?
Do you have any performance comparison?
> many more capabilities
As...? Care to compare?