Revisiting How We Put Together Linux Systems
0pointer.net
0pointer.net
For instance, the claim that the Linux packaging scheme doesn't work for proprietary, closed-source software. That's just plain wrong. No, proprietary software makers can't rely on distribution maintainers to package their stuff, however there is nothing preventing them from packaging it themselves, and making it available in a 3rd-party repository. Both deb/apt and rpm/yum have had this facility for ages, and it's how a lot of Linux users get either software not supported by the distro (like media stuff that Fedora refuses to include), or software that the distro drags its feet on updating. Proprietary vendors can easily use the same system to make their software available to users, and to allow the software to be easily kept up-to-date using the existing system instead of running a separate "update checker" constantly in the background like is common on Windows systems. The main problem is that there's more than one Linux distro out there, and they're not compatible with each other. But as Google does already with Google Earth and Chrome, for instance, it's not that hard to just target RH/Fedora and Debian/Ubuntu/Mint.
Another important point is libraries. They complain about the library dependencies all being different on different distros. But there's nothing stopping proprietary vendors from statically-linking everything, which is how they usually do it anyway, both on Linux and on Windows. Sure, it bloats up the binary, but it avoids a lot of library version and dependency problems, and with modern HD and RAM sizes, it's not that much of an issue.
It seems to me that they're proposing an enormously complicated and bloated system here in an effort to increase usage of desktop Linux, but this isn't going to help.
So it works, but I really wish we didn't have to maintain it.
Have you considered filing a feature request with the distributions about this? I can see why they do it this way, but there are certainly ways around this problem. (For example, a repo's metadata could include references to the identical repo for other OS versions, so that an upgrade can automatically switch to the appropriate repo.)
Google is quite an unusual case, though: they need to provides comparatively little end-user support for those products (relative to the absolutely huge sizes of the company and the user-bases). They already have the resources to build Linux versions, and they probably want them for their large internal pool of Linux users any way, but it is not business-critical to them whether Google Earth or even a given version of Google Chrome work well for you as a Linux user on your particular system. AFAIK they don't have to provide training, phone support or even a huge amount of detailed docs as part of offering the Linux builds of the products.
For companies with proprietary, licensed products, particularly the really feature-rich ones that focus on business or professional users, the product has to work without glitches or quirks on every platform that they support. When it doesn't, things rapidly get expensive: diagnosing bugs in the field and shipping fixes is still frequently time-consuming and labour-intensive. Even maintaining a test process for five Linux distributions to validate releases is not going to be cheap, and probably not cost-effective. They also need developers, QA and support staff with a working knowledge of two families of Linux.
And if they did it, they would consistently get requests for supporting more distributions, and have to keep politely saying "no" over and over again...
It does make economic sense for some companies to produce Linux versions of their products today, but I think that it's fair that each of them is unusual in some way. The situation needs to change for the economics to work for the average ISV.
> there's nothing stopping proprietary vendors ...
Yeah but they don't which is the whole point.
Likewise, proprietary vendors can "easily" publish UWP programs for Windows. They don't. Well I'm exaggerating a little, actually some of them do.
It's true, but they often manage to make a huge mess of it (note: entirely baseless remark based on my personal experience).
More importantly, most of them don't, and that sucks. I'm not sure why they don't, but I suspect that this is not the silver bullet?
How many here use Btrfs in production. Facebook does I think. Who else?
Tying something to the filesystem seems a good way to optimize and get a lot of benefit without too much work. But only if that file system is already prevalent.
But I am a bit worried about Btrfs. Is there even a consensus on Btrfs being "the future". There was at some point I think. I've seen https://bcache.evilpiepirate.org/Bcachefs/ touted as the "future" of FS on Linux.
EDIT: Oh 2014. Well it's already 2017 so the question is even more relevant regarding where do we see Btrfs heading?
On the flip-side, Synology just rolled out Btrfs in and update and I'm pretty sure it's the default partition type going forward. They don't expose all the fancy features like dedup, but the fact it's default shows some confidence.
So it sounds like it's being actively developed and getting closer to being trustworthy.
That said, when I bought a 916 last year, I ended up sticking with just ext4 as I needed something that would definitely work. I anticipate that I will at some point switch over.
Sure, you might need 5-10 lines of puppet or ansible to get it going in your linux of choice, but that's our job isn't it? And you're probably only using this on your storage boxes which are likely big pets instead of cattle (I use it on docker hosts too, but w/e)..
I've used ZFS in prod for 8 years at least (yay solaris, thumpers, fishworks etc) and it's never caused me any of the problems that things like VXFS, various sans, drbd etc have and I've run a bunch of pretty big infra on it (multi PBs).
Lets be realistic, you should really be picking your battles. Storage is almost always better to buy (read: cheaper/easier) than to build yourself unless you're one of the big boys (say, a cdn, some huge site with specific requirements or whoever.. Those folks probably have fs&kernel devs on staff).
As a responsible systems person you might tell your client just to give some money to emc or whoever as it'll be cheaper than having contractors build something where you need to care about filesystems, but if you absolutely must build it yourself, then go with the stuff that's mature, widely used and has all the nice features you might want from a FS (COW, Snapshots, compression, etc). Even then, probably your client won't have the staff to support your custom setup for more than about a year after you leave and they'll end up doing that anyway. Yes, I know some folks pulled it off; but I've not seen it yet...
As things stand, I cannot trust btrfs. I don't have a single reason to use a filesystem that has no users and has significant data loss issues in specific raid configs[0] when I have an alternative avail that works perfectly and is widely used and I have no idea why anyone else would either...
Losing data kills companies. You can't really fuck around with your software choices to do this stuff if you're a responsible person; save the fancy new tech for your apps not your infra....
There are, of course, gotchas with ZFS. You will get fragmentation on big pools over time which will hurt perf so you'll need to rebuild some storage nodes completely from time to time, but if you're building your own storage then this should be something you're capable of..
If you're custom building a few PB of redundant storage and your reason for not using zfs is you need to rebuild cluster nodes sometimes and you can't do that, then you shouldn't be be building storage on that scale.
BTRFS doesn't have that problem? Cool. I'd like to not have that problem too, but that doesn't mean that I'd use BTRFS just because I need to do those node rebuilds sometimes (which is good practice anyway isn't it?).
I'd maybe use in places I don't care about data safety, like as a storage driver for docker hosts (apps only) -- although I'd need a reason to bother trying...
Anyone?
Licensing: the ZFS license is, last I checked, incompatible with the GPL. That makes it a non-starter for me at least.
I will not make the mistake of putting any worth to suse's words again. Doing it again with btrfs shows they really have a knack for going edgy with filesystems while absolutely no other linux distribution is willing to recommend btrfs.
I trust the Red Hat guys to show more care and this is what they had to say only a year ago about btrfs:
https://www.reddit.com/r/linux/comments/37l2mf/i_am_matthew_...
"The btrfs developers keep telling us that it's not ready, so we're following that. (From one of our storage exports: "Btrfs will be ready in two years. The problem is, that's also going to be true next year, and in two years....") We try to be first where we can, but not at the cost of data loss for users.
-- Matthew Miller, Fedora Project Lead"
Doesn't look good to me.
As long as RH or Debian do not start recommending btrfs one cannot give it consideration in good conscience.
Considering a big chunk, possibly the single largest chunk, of upstream is Suse, and they use it by default for several years on both the opensuse and enterprise offerings, it doesn't really make sense at all that 'btrfs developers say it's not ready'. This just doesn't square. What's going on in my opinion is, neither Red Hat nor Fedora have the resources, nor are they willing to add resources, to triage Btrfs related bugs and therefore Fedora isn't ready for Btrfs, not the other way around.
Even Suse goes very light on what is supported with Btrfs multiple device stuff, by the way. Single device volumes, I've reported bunch of minor bugs, no data loss ever. Multiple device stuff is difficult to qualify: if you're familiar with the warts you're at a net advantage over mdadm and LVM RAID. If you're not and run into trouble, there are traps and Btrfs's claims of focusing on fault tolerance and ease of use can betray the user.
Just looked at this page: https://btrfs.wiki.kernel.org/index.php/Status and I can see how they would interpret that as "not ready". There a good number of "mostly OK" ones, one is unstable. With comments like "write hole still exists, parity not checksummed", "auto-repair and compression may crash ", and others.
It might be good enough for some but I can see many customers of Redhat would not want to trust their crown jewels to anything that stays "mostly OK".
That's like the ¯\_(ツ)_/¯ of storing things. Scary.
The systemd cabal (Kay Sievers, Harald Hoyer,
Daniel Mack, Tom Gundersen, David Herrmann,
and yours truly) recently met ...
Wouldn't you be paranoid if every one was against you?
Wouldn't you believe systemd is Cabal when the authors say so?It's a shame that it has such a steep learning curve.
Lots of folks are against a fundamental rethink. It'll have to be introduced a piece at a time (like with snaps and flatpak).
Hopefully we'll end up with something like nix in the end.
It is news in the light of the new events and the constant criticize that
1) systemd really is not living on the same planet anymore;
2) they really don't care about stability
3) they indeed have a secret agenda that is inherently based on both a misunderstanding and a destestation of the unix ways
On one hand I am excited by all these amazing things GNU/Linux will be able to do.
On the other hand, I often miss those simpler times in which you could install Slackware, boot it and now pretty much exactly what was running, where, how and why.
I'm not telling I want to go back though... Nowadays I can buy a not-so-old laptop, burn an Xubuntu usb stick and pretty much assume everything is going to work. I guess we will have to accept a tradeoff like this.
* abi/$triplet/{bin,sub,lib,int} Respectively binaries, private binaries, libraries, interfaces (headers)
2. Create a constraint based language to express package dependencies and make the deps fine grain (as in separate runtime from buildtime, etc).
3. Either make union mounts a first class citizen or restrict what an application can see via containers and part-out a complete system via containers instead of creating a complete system piecemeal.
Pottering is one of those "works for me" guys.