Alpine Linux is reducing dependencies on Busybox • Hacker News Board

Re: Alpine Linux is reducing dependencies on Busybox

#81

Post by pmarreck » Fri, Aug 05, 2022, 5:46 PM UTC

cortesoft wrote: post #38

yjftsjthsd-h wrote: post #19

Earlier quoted context omitted.

While I agree that it should be a standard feature, it is worth pointing out that operating systems tend to be more difficult and more expensive to run full tests for.

Yeah, the scope of things that an operating system needs to be able to do is basically, “all things that can be done on a computer”, so if you are trying to write full regression tests you are never going to hit all the possible combinations.

So because you see testing all the things together as too prohibitive, you balk at testing the individual bits in isolation (hence "UNIT" testing)?

Re: Alpine Linux is reducing dependencies on Busybox

#82

Post by pmarreck » Fri, Aug 05, 2022, 5:49 PM UTC

jhugo wrote: post #42

notacoward wrote: post #35

Earlier quoted context omitted.

Does that seem like a strong argument to you? Of course it's possible to make useless tests. It's possible to be injured by an airbag. It's possible to overdose on a drug that usually saves lives. That doesn't mean any of these things aren't generally beneficial, or that they should be foregone. As I said recently on Twitter, I've measured the likely cost of production bugs that were fixed early by static analysis, b…

I think it's a big assumption that the ROI of tests in general is in the same ballpark as the ROI of static analysis. In my experience, many tests written in commercial software engineering have ~zero or even negative ROI. This mostly applies to micro-level testing like unit tests; macro-level testing like integration tests can be fantastically valuable and I've even come to believe that they're the only type of test…

It depends on how you design your software and where the API surfaces are and how isolated the pieces can be made to be.

Which, if you're writing unit tests at the same time as the unit under test, leads naturally to pro-isolation, pro-modular designs, which are both easier to test, more reliable and generally have a more concise purpose.

Re: Alpine Linux is reducing dependencies on Busybox

#83

Post by notacoward » Fri, Aug 05, 2022, 9:50 PM UTC

pmarreck wrote: post #79

yjftsjthsd-h wrote: post #74

Earlier quoted context omitted.

It's not even just that, but also that a lot of the things OSs do are painful to artificially test because they're on the edge of hardware and software, or involve building the abstractions that let other software run without worrying about those details. How do you make a CI job that tests that mdevd correctly handles enumerating devices and setting their /dev nodes correctly, when the edge cases are finicky hardwar…

Does mdevd not send a signal or command out, and get one back? If so, the hardware behavior can be simulated, as can timing issues.

You can test the response to a signal that way, but testing whether it was sent when it should have been can get arbitrarily hairy. I've worked places where we had to do things like rig up relays to push physical buttons (or in one case physically pull a cable) to do this level of testing. An adjacent team (in 1994!) had an actual robot that would rove over the a disk-controller circuit board delivering small electric shocks to get the same kind of test coverage on the other end of the SCSI bus. When your code has to deal with devices, which can misbehave in arbitrary ways from the voltage levels on single electrical pulses up to complex protocol violations, simulating purely-software behaviors doesn't cut it. Maybe preach about the cost/benefit ratio of different kinds of testing after you've had to literally build the tests out in the physical world.

Re: Alpine Linux is reducing dependencies on Busybox

#84

Post by wpietri » Sat, Aug 06, 2022, 7:14 PM UTC

bruce_one wrote: post #40

wpietri wrote: post #37

Earlier quoted context omitted.

Oh, interesting! Anybody used s6? I like the theory, but for me what matters is mainly the practice.

We do - and have found it very reliable and I really like it :-) One of the members of our team finds it more complex when it comes to diagnosing why things aren't running/starting as expected, but that's also down to the complexity we have around s6 with other setup scripts (we use it to manage the full suite of processes in our product). Hence, they're not the biggest fan of it (and would talk negatively about it),…

Thanks! That makes sense to me. Personally, I usually like tools and practices that can feel rough when there's too much complexity. When there are problems, I think it's generally good that people feel like there are problems.

Re: Alpine Linux is reducing dependencies on Busybox

#85

Post by blueflow » Sat, Aug 06, 2022, 8:33 PM UTC

skarnet wrote: post #78

blueflow wrote: post #68

Earlier quoted context omitted.

You can already install coreutils and udev over busybox, without busybox being removed.

And if you look under the hood, you will see that it's only possible because of a bunch of ad-hoc hacks, which is exactly what my proposal was about: level the playing field and make it possible to have alternatives _without_ the ad-hoc hacks.

Are you referring to the busybox symlink farm?

Re: Alpine Linux is reducing dependencies on Busybox

#86

Post by pmarreck » Tue, Aug 09, 2022, 8:06 PM UTC

R0b0t1 wrote: post #34

notacoward wrote: post #8

Earlier quoted context omitted.

It saddens me too, but it still seems necessary. In my (quite long and varied) experience, most developers do not appreciate the value of regression tests. Therefore, reminders and positive reinforcement are still beneficial.

It is possible to make useless tests.

Yeah, what exactly are you arguing, here? "assert 1=1" is a useless test, that doesn't invalidate tests whatsoever

Re: Alpine Linux is reducing dependencies on Busybox

#87

Post by skarnet » Fri, Aug 12, 2022, 6:41 AM UTC

blueflow wrote: post #85

skarnet wrote: post #78

Earlier quoted context omitted.

And if you look under the hood, you will see that it's only possible because of a bunch of ad-hoc hacks, which is exactly what my proposal was about: level the playing field and make it possible to have alternatives _without_ the ad-hoc hacks.

Are you referring to the busybox symlink farm?

Not at all. I'm referring to the structure of the Alpine packaging, especially around boot scripts, that hardcodes busybox in a number of places and makes it difficult to package an alternative without workarounds - which accumulates tech debt.