|
|
Subscribe / Log in / New account

Poettering: Revisiting the fragmentation

Poettering: Revisiting the fragmentation

Posted Sep 2, 2014 8:59 UTC (Tue) by oldtomas (guest, #72579)
In reply to: Poettering: Revisiting the fragmentation by mezcalero
Parent article: Poettering: Revisiting how we put together Linux systems

> Same files will be de-dupped by btrfs.

So "lib compatibility" for an app means hash-equality of libs. Thanks for making that clear. Now I know this whole thing ain't for me.

I still cling to the old dream that an app has the responsibility of working with a whole range of environments (file system layout, minor variances in lib versions, etc.)

I don't care about the lazy app developers whose bloated monsters stop working because some file ain't in /etc/foo or because $libbar went from 1.2.7.15 to 1.2.7.16. I don't want to cater to that -- not on the boxes I'm responsible.


to post comments

Poettering: Revisiting the fragmentation

Posted Sep 2, 2014 16:00 UTC (Tue) by dskoll (subscriber, #1630) [Link] (3 responses)

+1

We work very hard to ensure our product runs on any Linux distro out there, as well as FreeBSD and pretty much any UNIX-like system. That's what proper programmers do.

Poettering: Revisiting the fragmentation

Posted Sep 3, 2014 2:57 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

> That's what proper programmers do.

Depends on the layer you're targeting. If you're writing a Linux driver, caring about FreeBSD doesn't make much sense.

Poettering: Revisiting the fragmentation

Posted Sep 3, 2014 6:58 UTC (Wed) by oldtomas (guest, #72579) [Link]

> Depends on the layer you're targeting. If you're writing a Linux driver, caring about FreeBSD doesn't make much sense.


I beg to differ: programming is abstraction. It always pays off to (a) make as little assumptions as might make sense and (b) make as many of those assumptions explicit as you ever can.

It not only makes other's lives easier (the poor FreeBSD gal/guy willing to use said device will thank you if she can rip off parts of your code, which for in-house use would be perfectly OK), but it ends up making the code clearer, more readable, and in the long term healthier.

Now I'd grant you that writing a kernel driver might put the tradeoff at another point that writing (say) an SMTP daemon, but "doesn't make much sense" seems to me too low a level for any case.

It's more work (as dskoll put it), but it's definitely worth it. And every time I see code like that, I thank the likes of dskoll.

Poettering: Revisiting the fragmentation

Posted Sep 3, 2014 15:44 UTC (Wed) by dskoll (subscriber, #1630) [Link]

Well, yes. :) I'm referring to applications, not kernel or driver programming.

Poettering: Revisiting the fragmentation

Posted Sep 3, 2014 22:31 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

I still cling to the old dream that an app has the responsibility of working with a whole range of environments (file system layout, minor variances in lib versions, etc.)
It would be nice... but in practice this means an exponential explosion of test environments, and what it really means is that your personal environment has never been tested by anyone but you, ever. Which means you get your own personal bugs. Now, I like this -- it means I get to help fix those bugs, and improve the quality of the software for everyone -- but for end users? Not so good.

Poettering: Revisiting the fragmentation

Posted Sep 4, 2014 7:04 UTC (Thu) by oldtomas (guest, #72579) [Link] (3 responses)

> but in practice this means an exponential explosion of test environments [...]

I think this is a very valid concern. Still, I think it's worth to take a step back and look at it from some distance: Tests, after all, are just a last line of defense. To keep software correct (or "as correct as possible"), we need first and foremost good interfaces. Meaning simple, understandable, well-designed. Small is paramount here -- you can't fulfill a contract you don't understand (and bad examples abound!).

By all means, test -- but first you gotta get a feeling that your software is doing the right thing.

Poettering: Revisiting the fragmentation

Posted Sep 4, 2014 14:15 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Agreed -- but given how hard it is to design good interfaces (much harder than writing the actual software, IMNSHO) and how often they churn... do you think we're anywhere near your utopia yet? Not really...

Poettering: Revisiting the fragmentation

Posted Sep 5, 2014 6:35 UTC (Fri) by oldtomas (guest, #72579) [Link] (1 responses)

> do you think we're anywhere near your utopia yet? Not really...

Strongly agree: not yet, and by a far stretch.

But utopia is a place to "move towards" and not to "be in", anyway. So watch me making uncomfortable noises whenever I think the direction is wrong.

And yes, designing a good interface is definitely the hard part. But it's rewarding. And we as a profession should insist on getting that reward :-)

Poettering: Revisiting the fragmentation

Posted Sep 5, 2014 16:17 UTC (Fri) by raven667 (subscriber, #5198) [Link]

It's hard to insist on anything when there is no barrier to entry for writing library code, anyone can write what they want, and anyone can use it regardless of its ABI discipline, if enough people use it then there is a lot of pressure to package it up for the major distros and the distros have shown a limited amount of pushback for enforcing quality standards on upstreams.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds