Software Updates
xkcd.com
Software Updates
1–10 of 149 posts
Re: Software Updates
#2This is IMO one of the greatest challenge the software engineering field needs to solve.
Re: Software Updates
#3Ultimately, the problem is that we are not good at creating stable APIs. If we did have stable APIs, then once something (a feature, or even entire software) is written agains this stable API it would be available forever. This is IMO one of the greatest challenge the software engineering field needs to solve.
Re: Software Updates
#4Ultimately, the problem is that we are not good at creating stable APIs. If we did have stable APIs, then once something (a feature, or even entire software) is written agains this stable API it would be available forever. This is IMO one of the greatest challenge the software engineering field needs to solve.
Re: Software Updates
#5Ultimately, the problem is that we are not good at creating stable APIs. If we did have stable APIs, then once something (a feature, or even entire software) is written agains this stable API it would be available forever. This is IMO one of the greatest challenge the software engineering field needs to solve.
ABI compatibility is also important. For example, the Linux kernel takes it very seriously but Linux user space generally doesn't. One of the reasons why application developers like to package dependencies together with the program in containers.
The linux kernel does not provide a stable ABI for drivers. Drivers that aren't in the kernel source tree will eventually break.
https://github.com/torvalds/linux/blob/master/Documentation/...
Re: Software Updates
#6Ultimately, the problem is that we are not good at creating stable APIs. If we did have stable APIs, then once something (a feature, or even entire software) is written agains this stable API it would be available forever. This is IMO one of the greatest challenge the software engineering field needs to solve.
Re: Software Updates
#7Earlier quoted context omitted.
ABI compatibility is also important. For example, the Linux kernel takes it very seriously but Linux user space generally doesn't. One of the reasons why application developers like to package dependencies together with the program in containers.
> ABI compatibility is also important. For example, the Linux kernel takes it very seriously The linux kernel does not provide a stable ABI for drivers. Drivers that aren't in the kernel source tree will eventually break. https://github.com/torvalds/linux/blob/master/Documentation/...
On the one hand it gives hardware vendors an incentive to contribute their drivers directly into their kernel but on the other hand most Android phones are now restricted to one old kernel version due to the lack of ongoing support from SoC vendors.
I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kernels are all outdated or even unmaintained.
Did this policy cause more harm than good?
Re: Software Updates
#8Earlier quoted context omitted.
ABI compatibility is also important. For example, the Linux kernel takes it very seriously but Linux user space generally doesn't. One of the reasons why application developers like to package dependencies together with the program in containers.
> ABI compatibility is also important. For example, the Linux kernel takes it very seriously The linux kernel does not provide a stable ABI for drivers. Drivers that aren't in the kernel source tree will eventually break. https://github.com/torvalds/linux/blob/master/Documentation/...
Re: Software Updates
#9Ultimately, the problem is that we are not good at creating stable APIs. If we did have stable APIs, then once something (a feature, or even entire software) is written agains this stable API it would be available forever. This is IMO one of the greatest challenge the software engineering field needs to solve.
Re: Software Updates
#10Earlier quoted context omitted.
> ABI compatibility is also important. For example, the Linux kernel takes it very seriously The linux kernel does not provide a stable ABI for drivers. Drivers that aren't in the kernel source tree will eventually break. https://github.com/torvalds/linux/blob/master/Documentation/...
I am not sure if this is good or bad. On the one hand it gives hardware vendors an incentive to contribute their drivers directly into their kernel but on the other hand most Android phones are now restricted to one old kernel version due to the lack of ongoing support from SoC vendors. I assume that the majority of Linux kernels are running on Android phones and due to this lack of stable ABI for drivers these kerne…
No, it's because the hardware manufacturers won't upstream their drivers. All they have to do is send the code licensed under GPLv2 and it will be updated and maintained.
Stable ABI for drivers will result in the Windows situation: hardware vendors will just release one driver for one Windows version and one processor architecture. They don't seem to care very much so why should people optimize for their comfort? The least they could do is release free software so that the people who do care can make it work well.
My laptop has a backlit keyboard with RGB LEDs. The only driver for it is a single proprietary Windows driver coupled with a buggy and slow application. I doubt these things will ever be updated.
I actually emailed the manufacturer about this. I asked for technical information in order to make it work on Linux. They didn't or couldn't help me. So I reverse engineered the keyboard, made a Linux program to control the LEDs and the result was much better than the software they wrote for Windows. At least it doesn't take a full minute to start up.
There is no point in making these companies comfortable. People should do the opposite: it should be as expensive as humanly possible to not release the drivers as free software. If they insist on maintaining proprietary drivers out of tree, then they should absolutely pay the maintenance cost. Kernel hackers shouldn't have to spend one second thinking about how a change will impact some crappy proprietary driver that's not even in the kernel tree.