4 ms·

Yeah, but do you really think any of that applies to things like the Linux kernel? You think with thousands of talented developers they have problems as simple

Yeah, but do you really think any of that applies to things like the Linux kernel? You think with thousands of talented developers they have problems as simple as duplicate code?

adgjlsfhk1 3y ago
absolutely. Any project with more than a couple dozen devs will have duplicated functionality (if not directly duplicated code). When you combine that with the loose coordination, I wouldn't be surprised if 20% of functionality in the linux kernel was duplicated.
- bluGill 3y ago
  The linux kernal has been very careful to deduplicate. Maybe you can find duplication between the scheduler and wifi drivers, but in general each subsystem does deduplicate.
  - vidarh 3y ago
    We rarely think of outright textual duplication (though there's plenty of that in Linux too - first file I checked I found multi-line segments of repeated code, though there's nothing wrong with that when it leads to simpler code). The more insidious duplication is the one that looks reasonable because it involves e.g. different filesystems, or other capabilities where it technically provides additional features, but practically doesn't. Clearing that out from an established project is near impossible because often there is someone out there who cares even though it'd make little practical difference to them. E.g. the ext2fs driver is still in Linux. "Technically" it offers extra functionality: You can use ext2fs without booting an old kernel in a vm. In practical terms, for a system starting from scratch, on the other hand, it offers no meaningful increase in capabilities. A not insignificant portion of Linux code is code like that which is there because someone cared at one point, and there's a legacy, and there's little real benefit to do more than not build a given driver by default. The core, non-driver parts of Linux itself is "cleaner" in that respect, but that too carries along legacy where it becomes a philosophical question whether removing a given thing strips functionality or not (e.g. the system might be able to do the same thing, but not in the exact same way)
vidarh 3y ago
More developers tends to make duplicated code more likely, not less, as people tend to work on percentage wise smaller subsets of the whole and fewer developers will have a semblance of an overview of the whole. Sometimes also even makes duplication sensible for a while if it allows shortcircuiting communications paths. The vast majority of kernel code is drivers. That's another reason why the Linux kernel code would be far bigger even if optimal. But it's also why it won't be optimal - the effort to figure out all the shared elements of every device out there is 1) not worth it, 2) going to take someone a lot of time to actually figure out commonalities that may not always be obvious. I've worked on a driver for the Linux kernel. We didn't even start to look at deduping it because the hardware in question would only ever have our device, and nobody else would have our device. But would there be duplication? Sure. The chip we used was common. For others it might be worth figuring out commonalities with other devices and eventually pare down the code. Or not.

Yeah, but do you really think any of that applies to things like the Linux kernel? You think with thousands of talented developers they have problems as simple as duplicate code?

adgjlsfhk1 3y ago

absolutely. Any project with more than a couple dozen devs will have duplicated functionality (if not directly duplicated code). When you combine that with the loose coordination, I wouldn't be surprised if 20% of functionality in the linux kernel was duplicated.

bluGill 3y ago
The linux kernal has been very careful to deduplicate. Maybe you can find duplication between the scheduler and wifi drivers, but in general each subsystem does deduplicate.
- vidarh 3y ago
  We rarely think of outright textual duplication (though there's plenty of that in Linux too - first file I checked I found multi-line segments of repeated code, though there's nothing wrong with that when it leads to simpler code). The more insidious duplication is the one that looks reasonable because it involves e.g. different filesystems, or other capabilities where it technically provides additional features, but practically doesn't. Clearing that out from an established project is near impossible because often there is someone out there who cares even though it'd make little practical difference to them. E.g. the ext2fs driver is still in Linux. "Technically" it offers extra functionality: You can use ext2fs without booting an old kernel in a vm. In practical terms, for a system starting from scratch, on the other hand, it offers no meaningful increase in capabilities. A not insignificant portion of Linux code is code like that which is there because someone cared at one point, and there's a legacy, and there's little real benefit to do more than not build a given driver by default. The core, non-driver parts of Linux itself is "cleaner" in that respect, but that too carries along legacy where it becomes a philosophical question whether removing a given thing strips functionality or not (e.g. the system might be able to do the same thing, but not in the exact same way)

vidarh 3y ago

More developers tends to make duplicated code more likely, not less, as people tend to work on percentage wise smaller subsets of the whole and fewer developers will have a semblance of an overview of the whole. Sometimes also even makes duplication sensible for a while if it allows shortcircuiting communications paths. The vast majority of kernel code is drivers. That's another reason why the Linux kernel code would be far bigger even if optimal. But it's also why it won't be optimal - the effort to figure out all the shared elements of every device out there is 1) not worth it, 2) going to take someone a lot of time to actually figure out commonalities that may not always be obvious. I've worked on a driver for the Linux kernel. We didn't even start to look at deduping it because the hardware in question would only ever have our device, and nobody else would have our device. But would there be duplication? Sure. The chip we used was common. For others it might be worth figuring out commonalities with other devices and eventually pare down the code. Or not.