Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018) • Hacker News Board

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#101

Post by saagarjha » Fri, Mar 20, 2020, 12:42 AM UTC

wtallis wrote: post #67

quotemstr wrote: post #66

Earlier quoted context omitted.

> Are you saying that wrapper code implementing an old interface by wrapping around a new interface is easier to do correctly in userspace than in the kernel itself? Yes. > I think I need you to be more concrete in pointing to a specific performance penalty or avoidable maintenance burden. I already did: socketcall. And NT does all 32-bit compatibility in userspace.

> I already did: socketcall Got anything that applies to modern platforms or recent kernel versions? Also, does socketcall actually have higher overhead than doing a similar dispatch in userspace, or does it just mean you get a cache miss slightly later in the process? (You could try elucidating an actual argument rather than just naming a syscall and assuming that the rest of your argument is obvious.) > And NT does…

Doing things in userspace prevents a context switch, presumably.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#102

Post by saagarjha » Fri, Mar 20, 2020, 12:44 AM UTC

carapace wrote: post #31

> We should look at the whole project [Linux] as a cautionary tale of the kind of leveraged destruction that some programmers of modest ability but extreme confidence can wreak on our industry. https://news.ycombinator.com/item?id=21168895

The people replying to that comment make a much better argument against the point it was trying to make that it does for it.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#103

Post by Gibbon1 » Fri, Mar 20, 2020, 1:00 AM UTC

AnthonyMouse wrote: post #11

> The only to prevent this would be to conduct regular massively coordinated updates to system utilities when the kernel changes, and properly version applications for specific kernel releases. Well, no. What you do is create a new struct with correct behavior and let new applications use that. The old struct becomes deprecated but continues to exist until things stop using it. Which may be indefinitely, but that's n…

I've been actively working on firmware that is now over ten years old. My advice tends to be if you have an api that takes a pointer to a structure you should have a version field from the get go.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#104

Post by loeg » Fri, Mar 20, 2020, 1:07 AM UTC

spacenick88 wrote: post #71

loeg wrote: post #38

Earlier quoted context omitted.

It seems like for many userspace applications, the appropriate backwards compatibility ABI would have been at the SO level. ELF shlibs make it easy to version interfaces without breaking old dynamically linked programs. Linux is sort of the odd duck in that it considers the entire syscall surface a stable ABI. It leads to a lot of neat results, but can obviously also cause pain when some older interfaces are not suff…

I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD. Also something like WSL would be impossible

> I would argue that the stable syscall interfaces is one of the main drivers behind Linux success. Containers as we know them would be quite different if they needed to somehow merge the kernel version appropriate .so files into the fs. They would forever remain just sandboxes of the essentially the same distro as the host just like they are on Solaris/FreeBSD.

I suspect the order of cause and effect is reversed. Linux is amazingly successful and as a result containers were shaped to fit the capabilities and needs of Linux. The reason Linux has a strong syscall ABI is because it doesn't have a userspace. Glibc is only loosely related to the kernel and cannot be the kernel's ABI compatibility layer, as they are wholly independent projects.

Another way of looking at this is that the overhead and additional abstraction of containers is a workaround for the deficiencies of Linux jail/zone facilities (i.e., it doesn't have them; you have to carefully piece together a secure sandbox out of various cgroup and namespace components).

> Also something like WSL would be impossible

Some interesting things about that:

1. WSLv1 was a partial Linux syscall emulator, sure.

2. Microsoft gave up on that approach and WSLv2 is just an Ubuntu VM running in HyperV. So maybe it was impossible anyway — Linux just provides a ton of system calls and it will always be difficult to faithfully implement all of them. And as some side threads have noted, Linux likes to break ABI of sysfs files all the time. But those don't count, for some reason.

3. FreeBSD has a linux syscall emulation layer (that long predates WSL) using essentially the same premise as WSLv1. You're correct that this style of implementation (syscall ABI) only works due to Linux's syscall ABI choices.

4. However, something like WSL is not impossible against a shlib ABI. The canonical example here is WINE. WINE implements (much of) the Windows NT shared library (DLL) level stable ABI. The same could be done for other systems that provide ABI stability at the DLL level, such as MacOS or FreeBSD.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#105

Post by JdeBP » Fri, Mar 20, 2020, 1:21 AM UTC

beagle3 wrote: post #86

JdeBP wrote: post #10

It's not quite that simple. People actually tried to update net-tools ifconfig (one of the two ifconfigs back in 2018). In 2019, I simply wrote an ifconfig that uses the netlink API, because for portability I needed a Linux ifconfig that had a FreeBSD-like command-line syntax. It doesn't have the old interface aliasing mentioned in the headlined article, and has no problems setting up and reporting IPv6 addresses or…

Thanks for nosh. Another off-topic question (using this forum as your author page is quite discouraging about sending you emails ....) What's the reason for naming cyclog files with the time they were closed? (other than that's how djb did it?), since this information is available easily with 'ls -l'? I use a logger that opens a $CREATE_TIMESTAMP.u file, and makes "current" a symbolic link to it; and on close renames…

If you want more than just my perspective, look to Laurent Bercot's Supervision Mailing list. M. Bercot is of course there, as well as a few other people.

* http://www.skarnet.org/lists.html

As for the filenames, yes the original reason was for compatibility with multilog, and of course all of the other tools that can process these log directories. I did set out, after all, to produce a cyclog workalike, with lessons from multilog incorporated. Note that said tools might not deal well with log directories where the same log file is available via two names, both "current" and something else.

Moreover, if you go and look at follow-log-directories you can see an additional benefit that it very efficiently skips its cursors over old files without having to look at their i-nodes because it knows that the filename is guaranteed to be a timestamp at or after the last log entry in the file.

Furthermore, if you go and read the cyclog manual, you'll find out why using the w permission bit had problems. (-:

1.41 is building up changes, by the way.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#106

Post by lathiat » Fri, Mar 20, 2020, 1:23 AM UTC

tialaramex wrote: post #95

Phemist wrote: post #76

Earlier quoted context omitted.

Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :) Edit: Interesting, https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk . serves the cert as mentioned above.

So, firstly don't put a dot at the end. Whatever you might feel about it, the decision in practice was that the host part of the URL is an FQDN but doesn't need a dot at the end. So don't write one there. The browser should probably trim it out when you type in or follow such a link. The Apache web server that the bulk host is using for that site has a fairly poor implementation of HTTPS. It's unsatisfactory in vario…

you can configure the first default apache vhost to be something else other than a "customer" site, that's what we do at my hosting company. though it still leads to a certificate error. that used to matter, but nowadays we just automatically lets encrypt everything that we host.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#107

Post by JdeBP » Fri, Mar 20, 2020, 1:36 AM UTC

comex wrote: post #93

zokier wrote: post #87

Earlier quoted context omitted.

> There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appearances. But it's telling that nobody stepped up and actually bothered to do that despite all the bitching and moaning. Successful code is generally produced to solve problems, not fullfil some abstract ideals

Except someone did rewrite it: https://news.ycombinator.com/item?id=22628938 But with the Linux ecosystem's inertia being what it is, rather than the 2 existing implementations of ifconfig in use being displaced by this better one... now there are just 3 implementations of ifconfig in use. As mentioned in the Stack Exchange thread linked in that post, a different someone submitted a relevant patch to one of those exi…

2009, in fact. I put it in the further reading.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#108

Post by justlexi93 » Fri, Mar 20, 2020, 1:56 AM UTC

The indirection allows for versioned APIs and compatibility shims, along with lengthening the migration window while not tying the kernel down and keeping it from fixing misdesigns or changing circumstances.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#109

Post by inshadows » Fri, Mar 20, 2020, 2:28 AM UTC

michaelmrose wrote: post #54

sheepdestroyer wrote: post #32

Earlier quoted context omitted.

ZFS is not user land. It's kernel code but without being in the kernel. So it has to be built separately and may not even be compliant with GPL (still has to be tested in court AFAIK). Linux's promise to not break userspace is just that, It can not be held responsible for code that should be in the kernel but does not play fair with the license.

It's not that it doesn't play fair. Sun published under a license that made inclusion in the kernel impossible thus the current developers are bound by the same decisions regardless of their opinion on the matter. Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux be…

> The extra work is 10 seconds of work. How childish and unprofessional.

While Oracle keeping the code under incompatible license for more than 10 years is totally OK.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#110

Post by inshadows » Fri, Mar 20, 2020, 2:39 AM UTC

loeg wrote: post #40

tw04 wrote: post #25

Earlier quoted context omitted.

That's a great theory, but Linus picks and chooses when to decide it's outrageous to make changes that break userland tools based on his personal preferences. They intentionally broke ZFS - then Linus follows up with a wildly inaccurate statement about why he thinks nobody should use ZFS. It's difficult to take him seriously when he picks and chooses when to enforce his supposed "never break userland" ethos.

For a scary few days he was considering completely breaking the ABI of getrandom(2). If he decides to break interfaces, I don't know that anyone can stop him. It is a downside to the BDFL model. Edit: Breaking ZFS is not a great example — as sibling comment points out, that is a kernel module using kernel-internal APIs, not userspace syscall ABI. The Linux kernel notoriously considers all kernel interfaces unstable.…

I think that it is a upside of BDFL model, unless it's someone incompetent. If you dig deep in the threads you'll find that so far his judgement on what to break or not has always been stellar. As long as you have someone as competent as Linus making the call, BDFL model is perfect.

RE getrandom(2): As Linus said several times, we don't break userspace rule does not apply to security bugs. If there's no other way to fix security bug other than breaking userspace, then userspace has to be broken, for obvious reason. If you don't understand that reason, you shouldn't really have a say in any such critical decision.