Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.farhan.codes

Post reply on HN
Print view View original

121–130 of 141 posts

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

#121

Post by yrro »

jandrese wrote: post #78
tene wrote: post #73

Earlier quoted context omitted.

While I agree that different defaults might be nice, modern versions of ip support a -br[ief] option which is pretty nice: $ ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 10.123.45.67/24 fe80::7ed3:aff:fe51:4612/64 $ ip -br l lo UNKNOWN 00:00:00:00:00:00 eth0 UP 7c:d3:0a:51:46:12

'ip -br a' get real messy if you have IP6 unfortunately. IPv6 hosts like to make lots and lots of addresses, which all get smooshed together on a single line of hard-on-the-eyeballs hex noise.

Adding 'scope global' to 'ip a' cuts down on some of the usually uninteresting addresses. More typing though.

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

#122

Post by jwilk »

tialaramex wrote: post #97
internalthief wrote: post #94

Earlier quoted context omitted.

It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in a .) For example, try the following: openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk." vs openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk" You'll notice that in the first case the default certificate is sent back, in the second case t…

The relevant RFC says not to send a trailing dot in SNI. Browsers should probably trim the dot out if present. Maybe they aren't doing so because it causes some unexpected compatibility mishap, maybe in reality it rarely causes any trouble so nobody got around to it.

https://tools.ietf.org/html/rfc3546#section-3.1

> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using UTF-8 encoding, without a trailing dot.

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

#123

Post by kelnos »

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…

To be fair, the third 'ifconfig' implementation is not compatible with the original in command-line options or in output, so adopting it would require changes just as adopting 'ip' does.

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

#124

Post by kelnos »

wmf wrote: post #60
uluyol wrote: post #58

Somewhere, the OS had to provide a stable interface. Why does it matter if it's in userspace vs the kernel? If you have to break the interface, it seems like applications have to be adjusted and/or recompiled, no?

It matters if userspace and the kernel are developed by separate teams, as is the case with Linux. If you break the kernel interface but have a library with a stable interface then you can't support static linking (which fell out of favor for a decade but is now back in style).

Right, and the article seems to have some sort of axe to grind with Linux, so the author paints "developed by separate teams" as somehow an inferior choice deserving of scorn.

I generally found the article to be light on technical accuracy and heavy on pointless "my OS is better than yours" prattle.

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

#125

Post by beagle3 »

JdeBP wrote: post #105
beagle3 wrote: post #86

Earlier quoted context omitted.

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…

> 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.

Thanks, that's two thing I've missed (because I never used it, I guess ..): This optimization and follow-log-directories+export-to-rsyslog which was introduced at a time I wasn't looking :)

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

:) Indeed, thanks.

> 1.41 is building up changes, by the way.

Thanks! And since I've missed follow-log-directories (and export-to-rsyslog) before, maybe there's another tool I've missed that would make shipping log directories more efficient? I'm concerned with very-low-bandwidth, very-intermittently-connected servers in which rsync is a godsend and e.g. rsyslog and friends proved much less reliable and efficient; And the renaming of "current" makes it miss the fact that it already has an (almost complete) copy of said file under a different name.

Thanks again!

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

#126

Post by throw0101a »

tylerl wrote: post #115
cyphar wrote: post #100

Earlier quoted context omitted.

The breakage of ZoL wasn't a side-effect of some big technical change. They literally just made the SIMD enable/disable barriers no longer usable from non-GPL modules (the changed an EXPORT_SYMBOL to EXPORT_SYMBOL_GPL). This means you can't use SIMD-accelerated hashing functions from ZoL -- and there is no way to fix it without hurting performance other than reverting the "license change". And the entire justificatio…

> ...disliked ZFS because they feel it was designed to be incompatible with Linux... Ya... That may have just a bit to do with the fact that ZFS is released under a licence that was explicitly designed to be incompatible with Linux. "Mozilla was selected partially because it is GPL incompatible. That was part of the design when they released OpenSolaris. ... the engineers who wrote Solaris ... had some biases about h…

Please stop spreading this. Simon Phipps, Sun's Chief Open Source Officer at the time, and the boss (?) of the person that you quote, has explicitly said this was not the case:

* https://marc.info/?l=opensolaris-discuss&m=115740406507420

Sun needed a file-based license that had patent provisions. There were none available at the time so they created their own. Given that CDDL-license technologies (Dtrace, ZFS) have been incorporated into other open source (BSD) as well as closed source projects (macOS) shows that it is quite accommodating.

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

#127

Post by inshadows »

michaelmrose wrote: post #117
inshadows wrote: post #109

Earlier quoted context omitted.

> 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.

What does it have to do with the zfs developers who no longer work for oracle?

It has to do with people barking at the wrong tree.

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

#128

Post by inshadows »

loeg wrote: post #114
inshadows wrote: post #110

Earlier quoted context omitted.

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…

> unless it's someone incompetent. Unfortunately, Linus is dangerously incompetent at cryptography. As was the case with getrandom(2). > RE getrandom(2): As Linus said several times, we don't break userspace rule does not apply to security bugs. I don't think you understand or correctly recall the scenario in which Linus nearly broke getrandom(2). The bug Linus was attempting to fix by breaking getrandom(2) was not a…

> Unfortunately, Linus is dangerously incompetent at cryptography. As was the case with getrandom(2).

I beg to differ. Of all people I know of, Linus is one of the most competent person when it comes to cryptography, more so than any of those Twitter celebrities. I suggest you dig into LKML archives. Exactly what in the case of getrandom(2) do you think makes him incompetent?

> I don't think you understand or correctly recall the scenario in which Linus nearly broke getrandom(2). The bug Linus was attempting to fix by breaking getrandom(2) was not a security bug. It was an availability bug, in userspace, caused by broken userspace code deadlocking itself.

I recall correctly. Optimizations in ext4 unveiled broken design of previous getrandom(2). To keep backward compatibility an easy choice could have been to supply early userspace with possibly predictable random numbers, which, of course would be a security issue. Another would have been to keep the bug hidden and revert any optimization that lowers early entropy pool. In the end, the solution at which the community arrived is best compromise given the constraints. The kernel is one of the few places where you can real software engineering to take place.

I think your comment is driven more by personal hatred for a great mind rather than technical merit.

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

#129

Post by opless »

loeg wrote: post #114
inshadows wrote: post #110

Earlier quoted context omitted.

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…

> unless it's someone incompetent. Unfortunately, Linus is dangerously incompetent at cryptography. As was the case with getrandom(2). > RE getrandom(2): As Linus said several times, we don't break userspace rule does not apply to security bugs. I don't think you understand or correctly recall the scenario in which Linus nearly broke getrandom(2). The bug Linus was attempting to fix by breaking getrandom(2) was not a…

Alas most people are incompetent when it comes to cryptography. It's another of those situations when if you don't know why something has to be done a certain way, you shouldn't be included in that decision making progress.

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

#130

Post by tyingq »

blaser-waffle wrote: post #52
JdeBP wrote: post #19

Earlier quoted context omitted.

See the StackExchange answer.

It's a comprehensive reply -- good stuff, and worth a read. The short version: > "As you can see, the GNU inetutils and NET-3 net-tools ifconfigs have some marked deficiencies, with respect to IPv6, with respect to interfaces that have multiple addresses, and with respect to functionality like -l. > The IPv6 problem is in part some missing code in the tools themselves. But in the main it is caused by the fact that Li…

That split where ioctl() is used for ipv4, and the send()/recv()/AF_NETLINK setup for ipv6 is interesting. I'm curious why the Linux folks chose that route. I'd get it as a temporary thing, but shouldn't they have migrated everything onto AF_NETLINK?
Post reply on HN