systemd Breached One Million Lines Of Code In 2017

[aht0]

Of course the idea of resolveconf=0 does not help those who are moving their computers between networks or switching on and off vpns. Setting resolvconf no does not prevent other items from updating /etc/resolve.conf.
So there is a issue around the way dns resolve has been done for a while. /etc/resolve.conf was design the idea of a static world. Not the dynamic world we now live in.
I have had the fun of attempting to use runit instead of sysvinit with debian and finding out how many places dependant on undocumented sysvinit behaviour.

And pray tell me, which particular items would these be? Network configuration in FreeBSD (for example in particular) is done by editing /etc/rc.conf in general or specific interface files in particular (when you need more specific settings for particular interface) in /etc by hand, using text editor - if you excluded some lone system utilities like dhclient, which is meant for network auto-configuration. When ready "on manual", you simply issue service netif restart on command line and voila.. There is no NetworkManager or bunch of other utilities you know from Linux. May look cumbersome but it actually is pretty convenient to use, once set up - even cellular connection. Single command from terminal window is usually enough for connecting/disconnecting/switching..

BSD's are not using sysvinit, none of them. rc-init or openRC (FreeBSD some derivatives). rc-init and sysvinit are different animals alltogether.

[oiaohm]

And pray tell me, which particular items would these be? Network configuration in FreeBSD (for example in particular) is done by editing /etc/rc.conf in general or specific interface files in particular (when you need more specific settings for particular interface) in /etc by hand, using text editor - if you excluded some lone system utilities like dhclient, which is meant for network auto-configuration. When ready "on manual", you simply issue service netif restart on command line and voila.. There is no NetworkManager or bunch of other utilities you know from Linux. May look cumbersome but it actually is pretty convenient to use, once set up - even cellular connection. Single command from terminal window is usually enough for connecting/disconnecting/switching..

BSD's are not using sysvinit, none of them. rc-init or openRC (FreeBSD some derivatives). rc-init and sysvinit are different animals alltogether.

What you have missed is software like openvpn could be editing /etc/resolve.conf directly having mid air collisions between openvpn and dhclient and others lead the resolveconf system or equal under Linux distributions to generate /etc/resolve.conf..

Service netif restart does not cause all application using a dns resolver to always update.

Yes when you go static configurations thing work ok ish. When you have to use more dynamic like VPN connections requiring you to change DNS settings on fly things got a lot more interesting.

Yes you have BSD people who say just static configure it. Not being aware that once you get into the more complex solutions the static configure comes path to fail. So the idea of editing everything in /etc by hand does not stack up any more.

if you excluded some lone system utilities like dhclient
This line is basically lets stick our head in sand and ignore all the different tools that collide at /etc/resolve.conf leading to failures in more complex setups.

There is a reason why systemd-resolved as a service exists.

It is also not straight forwards to attempt to replace bsd init in BSD with random inits. The BSD init and all it key parts are also under 1 project control. Same with openrc. Basically sysvinit was and is a mess. Systemd starts doing something in a non mess way then it gets yelled at for having too many parts in one. If I suggest breaking up all the parts using it bsd for init system into independent managed projects with no central management that would be insane right. Yet some how they way sysvinit was being developed was not insane what was exactly that.

[aht0]

What you have missed is software like openvpn could be editing /etc/resolve.conf directly having mid air collisions between openvpn and dhclient and others lead the resolveconf system or equal under Linux distributions to generate /etc/resolve.conf..

I went as far as actually testing OpenVPN client's behavior out on FreeBSD. Latest TrueOS Stable (FreeBSD 12-CURRENT with an OpenRC init)

• dhclient modified /etc/resolv.conf as it should.
• OpenVPN client changed /etc/resolv.conf as well but shutting it down or even crashing openvpn-client (crashing as"Sat Jan 20 20:22:30 2018 SIGINT[hard,] received, process exiting") reverted /etc/resolv.conf instantly back to it's previous state.
• While OpenVPN client was running, first name server in /etc/resolv.conf was OpenVPN's. Second name server was what was originally dished out by DHCP server in LAN and set by dhclient.
• Second request by dhclient from LAN DHCP server while openvpn-client was running, did pull in new IP configuration for the interface but did not modify /etc/resolv.conf at all.

Service netif restart does not cause all application using a dns resolver to always update. Yes when you go static configurations thing work ok ish. When you have to use more dynamic like VPN connections requiring you to change DNS settings on fly things got a lot more interesting.

I'd have to test it out on vanilla FreeBSD as well but on TrueOS restarting net did not make not single change into DNS settings. Command rc-service network restart simply restarted every network-related service one-by-one and every interface without making changes into /etc/resolv.conf. Same with simply restarting particular network interface (rc-service network.re0 restart)

There is a reason why systemd-resolved as a service exists.

And it would be? As far as I see, using dnsmasq tends to work out better on average.

It is also not straight forwards to attempt to replace bsd init in BSD with random inits. The BSD init and all it key parts are also under 1 project control. Same with openrc.

It's far easier than doing the reverse, porting Linux-specific code over to BSD's, which still is done constantly. Porting from BSD towards Linux would not even cause any problems license-wise.

Fork it, GPL the fork and do your necessary changes - control over the fork is in your hands from that point on. It's not like there would be much if any development happening upstream to rc-init : "When it works, it works - don't fuck with it" - philosophy. So, it obviously does not matter who controlled or did not control the upstream.

OpenRC is a Linux-domain project (Gentoo) AFAIK.

It's unclear how the situation would be worse than with systemd now. Of which development (22 devs) is mostly controlled by single commercial entity (yeah I know there are also Google reps among it's devs and some others, it does not make much of a diff) and everyone else are generally just tagging along on the ride without much control. Even refusing systemd causes excessive additional work (look at devuan and others).

Basically sysvinit was and is a mess. Systemd starts doing something in a non mess way then it gets yelled at for having too many parts in one.

And while doing it, do it the usual Linux-way? Ignore existing solutions, instead of building upon their strengths, start completely over and produce something internally excessively complicated, hard to debug, hard to get around from and hard to go without with.

I am not even sure how to actually think about it. On one end, it's obvious that future brings Linux distributions that are like mirror images of each-other (systemd, unified package management systems like flatpack). It would end the fragmentation of Linux world and at the same time would kill off it's major strength - polymorphism. It'd be pretty much just "another Windows" eventually.

If I suggest breaking up all the parts using it bsd for init system into independent managed projects with no central management that would be insane right. Yet some how they way sysvinit was being developed was not insane what was exactly that.

Don't lose focus. What did Linux obviously need? "Better init" and "better service management", correct? Sysvinit's major problem was the fact it could not return service status properly and getting around that was rather cumbersome task. What else? Desktop users did not care either way. Sysvinit served them well. Symlinks mess and other reasons presented as justification for systemd-init bothered really whom? Distributors and those server admins who had to orient themselves in it. For everyone else, it was too deep under the hood.

What could have been done without producing hundreds of thousands LOC under systemd:
- could have used OpenRC - which had already service management (look at rc-service command I used above), parallel init, dependency system and so forth..
- port BSD init. Which has already even been emulated in the oldest Linux alive today - Slackware. Half the work done right there. Just get rc-init itself actually ported and rest would follow without much fuss. No symlink mess nomore. You don't like shell scripts? Make init start fucking python, perl or lisp interpreter and use actual perl/python/lisp scripts - lisp especially is very fucking fast. Some distros used that idea even with old sysvinit (perl/python at least)

Rest of the features of the systemd? Do you really-really need more than fraction of it's present-day features and how many were truly not attainable using alternative existing tools? Pre-boot message logs? How much and often have you really needed that? Binary logs? I can see usability for enterprise world. Nothing else strikes me as irreplaceable though.

[oiaohm]

I went as far as actually testing OpenVPN client's behavior out on FreeBSD. Latest TrueOS Stable (FreeBSD 12-CURRENT with an OpenRC init)

• dhclient modified /etc/resolv.conf as it should.
• OpenVPN client changed /etc/resolv.conf as well but shutting it down or even crashing openvpn-client (crashing as"Sat Jan 20 20:22:30 2018 SIGINT[hard,] received, process exiting") reverted /etc/resolv.conf instantly back to it's previous state.
• While OpenVPN client was running, first name server in /etc/resolv.conf was OpenVPN's. Second name server was what was originally dished out by DHCP server in LAN and set by dhclient.
• Second request by dhclient from LAN DHCP server while openvpn-client was running, did pull in new IP configuration for the interface but did not modify /etc/resolv.conf at all.

I'd have to test it out on vanilla FreeBSD as well but on TrueOS restarting net did not make not single change into DNS settings. Command rc-service network restart simply restarted every network-related service one-by-one and every interface without making changes into /etc/resolv.conf. Same with simply restarting particular network interface (rc-service network.re0 restart)
And it would be? As far as I see, using dnsmasq tends to work out better on average.

Have to have another look at BSD. I do know I have seen dhclient and openvpn open resolv.conf at the same time and stuff it up. Reason for debian resolvconf system where dhclient and openvpn write into their own files and then a script that takes out a lock does the merge making the /etc/resolv.conf. And that is from the sysvinit days.

It also still leave the problem of programs who started before the /etc/resolv.conf change and have not changed to the new setting. Really we need a method that will update resolv configuration without needing to restart the applications that is standard.

OpenRC is a Linux-domain project (Gentoo) AFAIK.

OpenRC is one of the project that is being developed that stands a chance of making a init system that in fact works multi platform instead of a init that only party works as most multi platform inits have been.

It's unclear how the situation would be worse than with systemd now. Of which development (22 devs) is mostly controlled by single commercial entity (yeah I know there are also Google reps among it's devs and some others, it does not make much of a diff) and everyone else are generally just tagging along on the ride without much control. Even refusing systemd causes excessive additional work (look at devuan and others).

The reality here is you can now see that. With sysvinit with all the parts to boot a system they were either maintained almost 100 percent by redhat or nobody at all.

So when systemd started and redhat pulled there resources from sysvinit and putt them on systemd and groups like devuan attempted to pick up what was left it kind come clear how much work redhat was in fact doing. The so called excessive additional work is that everyone was leaving it to redhat in the first place now they have to do something.

I am not even sure how to actually think about it. On one end, it's obvious that future brings Linux distributions that are like mirror images of each-other (systemd, unified package management systems like flatpack). It would end the fragmentation of Linux world and at the same time would kill off it's major strength - polymorphism. It'd be pretty much just "another Windows" eventually.

Problem there is a massive number of distributions but at core there are not very much unique. Think a lot of distributions changes from sysvinit to systemd at the same time because they were just using what redhat was providing. Debian was latter and then you watched most debian based distributions also do exactly parent did. Polymorphism in Linux had mostly disappeared by 1998 most distributions created after that date are mostly just use the same core as parent distribution and the Polymorphism was mostly window dressing bits.

Don't lose focus. What did Linux obviously need? "Better init" and "better service management", correct? Sysvinit's major problem was the fact it could not return service status properly and getting around that was rather cumbersome task. What else? Desktop users did not care either way. Sysvinit served them well. Symlinks mess and other reasons presented as justification for systemd-init bothered really whom? Distributors and those server admins who had to orient themselves in it. For everyone else, it was too deep under the hood.

Desktop users do care when they cannot like successfully restart their print server when something has gone wrong this is something sysvinit would fail todo. Working service management is kind of important to desktop users even if they don't very often but when they do need service management it must work.

What could have been done without producing hundreds of thousands LOC under systemd:
- could have used OpenRC - which had already service management (look at rc-service command I used above), parallel init, dependency system and so forth..
- port BSD init. Which has already even been emulated in the oldest Linux alive today - Slackware. Half the work done right there. Just get rc-init itself actually ported and rest would follow without much fuss. No symlink mess nomore. You don't like shell scripts? Make init start fucking python, perl or lisp interpreter and use actual perl/python/lisp scripts - lisp especially is very fucking fast. Some distros used that idea even with old sysvinit (perl/python at least)

There is a scary fact here the memory foot print of all the bash starts in sysvinit is larger than the memory foot print of systemd. So there is a reason to move away from using a complete language like python perl or lisp. Debian used dash with sysvinit to save on memory foot print.

Also port BSD init does not exactly work. Due to Linux kernel design only really effective way to track what was started in a service is put service in cgroup/namespace.

There is a difference in the way BSD kernels and Linux kernels do their process trees and the result is BSD can track what started what and the Linux kernel loses what started what. It is beneficial for performance in large NUMA systems to run the process tree the way the Linux kernel does. So BSD init on Linux is like sysvinit on Linux it does not quite fit right then it does not behave right. sysvinit works perfectly on a sysv operating system but Linux is not a sysv operating system. BSD init works perfectly on BSD kernel again Linux is not a BSD kernel.

OpenRC is design smartly to include platform dependant code around services so when on Linux it can do what Linux needs when on BSD it can do what BSD needs. OpenRC is really how cross platform init systems should look. If a init system claims to be multi platform and you are not seeing sections of platform dependant code they are fibbing its will be broken on one of the platforms they claim.

OpenRC I see as a valid alternative to watch. The idea of port BSD init or using some of the older not properly Linux compatible inits need to disappear and those resources focused either into a new project to design a cross platform init correct or in openrc or just simply accept systemd like they use to accept sysvinit..

Rest of the features of the systemd? Do you really-really need more than fraction of it's present-day features and how many were truly not attainable using alternative existing tools? Pre-boot message logs? How much and often have you really needed that? Binary logs? I can see usability for enterprise world. Nothing else strikes me as irreplaceable though.

Please note its not pre-boot message logs. The messages from kernel start to userspace start were being lost. This can be kind important when you wake up that some of the messages being lost can be like ECC memory error messages. So most of those message not important to desktop user but some of them are and they were being lost and not picked up by anything.

[aht0]

Have to have another look at BSD. I do know I have seen dhclient and openvpn open resolv.conf at the same time and stuff it up. Reason for debian resolvconf system where dhclient and openvpn write into their own files and then a script that takes out a lock does the merge making the /etc/resolv.conf. And that is from the sysvinit days.

It also still leave the problem of programs who started before the /etc/resolv.conf change and have not changed to the new setting. Really we need a method that will update resolv configuration without needing to restart the applications that is standard.

Maybe because FreeBSD (and NetBSD for that matter) makes use of openresolv in their respective base systems, which is meant to handle just this particular problem. Which, incidentally should work on sysvinit Linux too. You may of course, do as you will, use systemd and let it try to fight it out.

"Order of boot" itself is plainly defined in /etc/rc.conf . You do not want one program starting ahead of another? Just write the entry for the program you want to start sooner, higher into /etc/rc.conf . And avoid writing network settings below "daemon" (like SSH or OpenVPN) entries. Problem solved. The content of this file is executed in a linear manner. It's not a problem you'd see, unless you are doing your manual editing of this file very first time.

OpenRC is one of the project that is being developed that stands a chance of making a init system that in fact works multi platform instead of a init that only party works as most multi platform inits have been.

It already works on GNU/Linuces, Linuces using musl C-library, on FreeBSD and on NetBSD. Dunno, probably with slight code adjustments on other variation of BSD (Open or DFly) too.

Problem there is a massive number of distributions but at core there are not very much unique. Think a lot of distributions changes from sysvinit to systemd at the same time because they were just using what redhat was providing. Debian was latter and then you watched most debian based distributions also do exactly parent did. Polymorphism in Linux had mostly disappeared by 1998 most distributions created after that date are mostly just use the same core as parent distribution and the Polymorphism was mostly window dressing bits.

Basically I think you are correct. What I meant though - with more and more uniform experience, newcomers have less and less motivation for exploring. Distro-hopping and thrill of trying to find something new was a factor that compensated a lot of shortcomings Linux had and still has, compared to Windows. It was just fun to see what's different in the next one. At some point you started to appreciate the OS itself.

Imagine uniform Linux: newcomer coming from Windows, installing Linux, finding he or she really can't play on it or do something else he/she would like to, tries another "uniform" distro - finds it to be much the same with little, mostly visual differences - and goes back to Windows.

Desktop users do care when they cannot like successfully restart their print server when something has gone wrong this is something sysvinit would fail todo. Working service management is kind of important to desktop users even if they don't very often but when they do need service management it must work.

Not really, stuff like this is usually handled by some GUI or other. That's the very point of desktop, isn't it? Percentage of users who'd bother themselves digging under the hood is minuscule (only enthusiasts), unless the distro itself is meant to be tweaking/tune/DIY like Arch or Gentoo.

There is a scary fact here the memory foot print of all the bash starts in sysvinit is larger than the memory foot print of systemd. So there is a reason to move away from using a complete language like python perl or lisp. Debian used dash with sysvinit to save on memory foot print.

Memory foot print is meaningless on a PC platform where memory is usually rather abundant. Memory foot print on embedded - different story. Though with seriously limited memory (linux routers for example) it's usually place you won't see systemd either. Because it's memory foot print is too big. Busybox, musl and sysvinit - these yes.

Also port BSD init does not exactly work. Due to Linux kernel design only really effective way to track what was started in a service is put service in cgroup/namespace.
There is a difference in the way BSD kernels and Linux kernels do their process trees and the result is BSD can track what started what and the Linux kernel loses what started what. It is beneficial for performance in large NUMA systems to run the process tree the way the Linux kernel does. So BSD init on Linux is like sysvinit on Linux it does not quite fit right then it does not behave right. sysvinit works perfectly on a sysv operating system but Linux is not a sysv operating system. BSD init works perfectly on BSD kernel again Linux is not a BSD kernel.

Well, okay. I know that internals behave differently (FreeBSD has kqueue, Linux has no such animal). Use BSD init as a "role model" and produce shim that would behave like one, if you figure porting it straight is insurmountable. It's still far less work that writing hundreds of thousands LOC.

Please note its not pre-boot message logs. The messages from kernel start to userspace start were being lost. This can be kind important when you wake up that some of the messages being lost can be like ECC memory error messages. So most of those message not important to desktop user but some of them are and they were being lost and not picked up by anything.

ECC errors are rare. First, ECC error would have to happen at all. Once-twice in a year tops when machine is running 24/7/365? Then it would have to happen in a very limited time frame to fill the particular need ("from kernel start to userspace").. how OFTEN you do start your computer anyway? Server which runs with minimal downtime does not need that feature actually at all. When you have faulty RAM stick, it spams complaints about memory errors on a continuous basis anyway - you'd notice the problem anyway.

Had 6C/12T Xeon HP workstation as a "home gaming PC" for 3-4 years. ECC RAM, only had to replace GPU against consumer model. I few times tried to find memory error from logs, didn't find any, ever. WIndows's Event Viewer should log such, upon occurrence.

[oiaohm]

Maybe because FreeBSD (and NetBSD for that matter) makes use of openresolv in their respective base systems, which is meant to handle just this particular problem. Which, incidentally should work on sysvinit Linux too. You may of course, do as you will, use systemd and let it try to fight it out.

openresolv is a BSD port of resolveconf from debian. https://roy.marples.name/projects/openresolv Just like the debian resolveconf it does not make sure all running applications in fact update their resolve information. So its not openresolv that is the difference.

"Order of boot" itself is plainly defined in /etc/rc.conf . You do not want one program starting ahead of another? Just write the entry for the program you want to start sooner, higher into /etc/rc.conf . And avoid writing network settings below "daemon" (like SSH or OpenVPN) entries. Problem solved. The content of this file is executed in a linear manner. It's not a problem you'd see, unless you are doing your manual editing of this file very first time.

Exact fixed order of boot is not that efficient on modern multi core systems. Openrc like systemd does include a parallel boot option but it on TrueBSD is off by default but systemd linux systems parallel boot is on. So at some point we do have to address these collision points.

It already works on GNU/Linuces, Linuces using musl C-library, on FreeBSD and on NetBSD. Dunno, probably with slight code adjustments on other variation of BSD (Open or DFly) too.

Yes openrc worked correctly using what those platforms provide to do proper service management. But at the time of the Linux world change from sysvinit to systemd openrc was still having more crash issues than systemd was at the time. Some point in future more openrc distributions may get support.

Basically I think you are correct. What I meant though - with more and more uniform experience, newcomers have less and less motivation for exploring. Distro-hopping and thrill of trying to find something new was a factor that compensated a lot of shortcomings Linux had and still has, compared to Windows. It was just fun to see what's different in the next one. At some point you started to appreciate the OS itself.

There is a big downside to Distro-hopping. It called the grass is greener on the other side of fence problem.

You look over the fence think it greener you jump over the fence you look back you think it greener because the sun moved. Result you don't water any grass and the grass dies. Distro-hopping is the same thing instead of reporting bugs and attempting to get problems fixed person would just change to another distribution most of the time based on exactly same thing with exactly the same problem and then distro-hop again and again until they give up and return to windows. Upstream developer know nothings of these problems because they were never reported.

Distro-hopping caused more problems than good.

Not really, stuff like this is usually handled by some GUI or other. That's the very point of desktop, isn't it? Percentage of users who'd bother themselves digging under the hood is minuscule (only enthusiasts), unless the distro itself is meant to be tweaking/tune/DIY like Arch or Gentoo.

LOL no proper service tracking under old Linux you have a GUI that for sysvinit that meant to be able to restart services and something locked files in print que you got to restart cups now it completely stopped and will not start. That is where people using GUI use to end up on Linux. There is need for some form of service management that can correctly kill and restart services so a GUI that can kill and restart services that works can be made. This reason alone is why sysvinit had to be replaced by something.

Memory foot print is meaningless on a PC platform where memory is usually rather abundant. Memory foot print on embedded - different story. Though with seriously limited memory (linux routers for example) it's usually place you won't see systemd either. Because it's memory foot print is too big. Busybox, musl and sysvinit - these yes.

Busybox+musl+sysvinit has a bigger memory foot print than minimal systemd. Yes systemd has a lot features that can be turned off and when you turn off all the features to match it to what busybox+musl+sysvinit provide the result is systemd lighter than the mixed beast.

Well, okay. I know that internals behave differently (FreeBSD has kqueue, Linux has no such animal). Use BSD init as a "role model" and produce shim that would behave like one, if you figure porting it straight is insurmountable. It's still far less work that writing hundreds of thousands LOC.

There are already wrappers for kqueue. Like https://github.com/mheily/libkqueue Problem is you use them you find your you service tracking is not working any more. Linux the only way that works for proper service tracking is cgroup/namespace anything else you will get caught by one of the different behavours. Upstart attempted 9 different methods include what BSD init does and they don't work with the Linux kernel. The closest they got was a ptrace that end up causing other problems. Then upstart gave up when they worked out they would have to implement cgroups/namespace support and went systemd.

Also this is another area where its going to cause problems for openrc. Systemd found a lot of bugs in cgroups that is now called cgroupsv1 there is now a cgroupsv2 that works better that openrc has not started support for.

The reality was when systemd started there was nothing under Linux that could do proper service management due to all the different issues coming from the kernel. And still there are other init systems other than systemd that are up to date on doing it.

Really I would like to see openrc improve and more init solutions that include working service management on LInux.

ECC errors are rare. First, ECC error would have to happen at all.

Yes on compatible hardware these errors are rare. On incompatible hardware not so much. When you see ECC errors early boot on a desktop motherboard who cpu and motherboard does not support ECC you know you have a big compatibility problem/possible cpu with unstable id(if the problem is random). Like sometimes the reason a sound card is not working on random boots could be a message early on in the kernel process that was being lost as well.

Not logging that early boot stuff is a problem with some of the random issues that do come from firmware and other places.

[pavlerson]

This is wrong. Because a code base from a skilled developer may have asserts and other runtime tests inside the code. So the 10 000 lines of code could have runtime testing the 2000 lines is written by a novice who did not include runtime testing living in the world of hope and pray everything is right.

As I said, if both code bases are equal, but one code base use twice as many LoC to do the same thing as the other code base - then the first code base is bad. This includes asserts, error checking, etc. You make the assumption that one code base do more things; asserts, error checking, etc. That is not what I talk about. Both code bases are equivalent, ie. they catch the same errors, etc. They are equivalent in all aspects - but one is more wordy. In that case, the less verbose code has been written by the better developer.

If you dont believe me, talk to any professional developer. Not a beginner.

[starshipeleven]

As I said, if both code bases are equal, but one code base use twice as many LoC to do the same thing as the other code base - then the first code base is bad. This includes asserts, error checking, etc. You make the assumption that one code base do more things; asserts, error checking, etc. That is not what I talk about. Both code bases are equivalent, ie. they catch the same errors, etc. They are equivalent in all aspects - but one is more wordy. In that case, the less verbose code has been written by the better developer.

In this specific case with specific assumptions you created yourself you are right, but what does this tell about real-life situations?

[pavlerson]

In this specific case with specific assumptions you created yourself you are right, but what does this tell about real-life situations?

What? I said from the very beginning "if both code bases are EQUAL then the smaller code base is better engineered".

Then "oiaohm" said "but assume they are not equal, assume one code base has lots of asserts and tests and the other code base lacks those tests" - well then the code bases are NOT equal, so the discussion is moot. Either he or you does not understand what "equal functionality does mean"

[unixfan2001]

What does equal even mean? Like. Can one be written in Golang and the other in C++, as long as they exhibit the same feature set/expose the same interface?
What about comments? While I agree that good code shouldn't necessarily need particularly wordy comments, some of us actually use comments (in combination with the underlying code) to generate API documentation, styleguides or literate documentation.

Or what about the opposite direction? A program using things like var e; is most assuredly shorter than one defining properly named, block scoped variables. But is it better?