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

Not knowing the /proc file system

admccartney.mur.at

Post reply on HN
Print view View original

71–80 of 111 posts

Re: Not knowing the /proc file system

#71

Post by Terr_ »

enriquto wrote: post #64
9dev wrote: post #2

Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?

> Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. I definitely make a point of using only single-letter variables in most of my C and python programs. It is a very common usage in scientific computing. In math, all variables are single letters. Always. If a variable has more than one letter, you rea…

That one lands near the margin-of-error for my sarcasmometer, but either way I'd like to emphasize (non-ironically) that the terse form is indeed very efficient... for someone repeatedly writing/copying it down by hand using a quill and ink.

However that particular use-case has become dramatically less significant.

Re: Not knowing the /proc file system

#72

Post by xyzelement »

School-Cotton wrote: post #62
xyzelement wrote: post #28

Earlier quoted context omitted.

And I would say that’s a good case where the long name is meaningful and necessary. On the other hand when you are dealing with a file pointer in a language that deals with file pointers constantly, “fp” is meaningful enough.

CNLabelContactRelationBiaoMei would have been a lot better. People can look up what that means when they need to.

I haven't been a dev in a bit, but I'd say between having a longer variable name, and having to crack open the fucking dictionary.... I have a clear preference.

Re: Not knowing the /proc file system

#73

Post by xxpor »

School-Cotton wrote: post #62
xyzelement wrote: post #28

Earlier quoted context omitted.

And I would say that’s a good case where the long name is meaningful and necessary. On the other hand when you are dealing with a file pointer in a language that deals with file pointers constantly, “fp” is meaningful enough.

CNLabelContactRelationBiaoMei would have been a lot better. People can look up what that means when they need to.

You have to worry about discoverability the other way: how would I (dumb american) know that's something I should be worried about?

Re: Not knowing the /proc file system

#74

Post by anonacct37 »

marcosdumay wrote: post #46
Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

> The Linux kernel has no standard mechanism for delivering a variable-sized result from a system call. Maybe we can expand the userspace networking interfaces, and make a fully featured messaging system. Some day Linux may even reach feature parity with L4!

Not an expert, but I've seen some signs that netlink is used instead of ioctl lately. https://medium.com/thg-tech-blog/on-linux-netlink-d7af1987f8...

Re: Not knowing the /proc file system

#75

Post by spacechild1 »

mananaysiempre wrote: post #40

> I’m using a custom function for reading lines from a file. [Listing: fgetLine()] It’s probably easier to just use getline(), it does basically the same thing and is in POSIX.1-2008[1]. [1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

AFAICT, getline() is not available on Windows, neither with MSVC nor MinGW.

The actual solution is to use C++ instead of C :)

Re: Not knowing the /proc file system

#76

Post by enriquto »

Terr_ wrote: post #71
enriquto wrote: post #64

Earlier quoted context omitted.

> Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. I definitely make a point of using only single-letter variables in most of my C and python programs. It is a very common usage in scientific computing. In math, all variables are single letters. Always. If a variable has more than one letter, you rea…

That one lands near the margin-of-error for my sarcasmometer, but either way I'd like to emphasize (non-ironically) that the terse form is indeed very efficient... for someone repeatedly writing/copying it down by hand using a quill and ink. However that particular use-case has become dramatically less significant.

Heh. No sarcasm at all in my comment! (but I like to write in an over the top way...)

Terse notation has nothing to do with manual handwriting. Modern math books and articles are still written by computer using a very terse symbolic notation, which has been developed during the last six centuries. Originally, the symbols +, = were shorthand abbreviations of Latin words.

I guess computer scientists want to re-invent everything from scratch. How long will they need to evolve from "LinearAlgebra.matrixVectorProduct(,)" to the empty string? I hope it's less than six centuries!

Re: Not knowing the /proc file system

#77

Post by AndrewDavis »

JdeBP wrote: post #53
chasil wrote: post #50

Earlier quoted context omitted.

I believe that the /proc filesystem first appeared commercially in Solaris, and was then adopted and expanded in Linux. I got an SDF account recently, and was surprised to find it in NetBSD. OpenBSD has great resistance to it. ...looking at the wiki, many more kernels implement /proc: "Many Unix-like operating systems support the proc filesystem, including Solaris, IRIX, Tru64 UNIX, BSD, Linux, IBM AIX, QNX, and Plan…

The problem is Wikipedia being misleading again. They each support a proc filesystem. There is no single the proc filesystem that they support. A case in point: FreeBSD's /proc is very different to Linux's /proc, and most of what one would go to /proc on Linux for is obtained via sysctl() on FreeBSD, with a lot less in the way of machine readable → human readable → machine readable busywork formatting and re-parsing…

Roger Faulkner's 1991 paper is good read. The /proc he describes looks alien if you come from a Linux only background.

https://www.usenix.org/sites/default/files/usenix_winter91_f...

Re: Not knowing the /proc file system

#78

Post by jsrcout »

rascul wrote: post #24
lifthrasiir wrote: post #7

Earlier quoted context omitted.

Maybe your tangent is pointing at a wrong direction, because I think there are also a sizable portion of such programmers in many other languages. It seems that anOverlyLongAndInformationFreeIdentifier is widely despised, but once names do have enough information contents, an exactly preferred name wildly varies even in a single code base. For example induction variables in Python generators tended to be shorter than…

> anOverlyLongAndInformationFreeIdentifier Apple has one 82 characters. https://developer.apple.com/documentation/contacts/cnlabelco...

I once worked with safety critical code that had a variable name 62 characters long, without any extra fluff. It made sense in context. The problem was disambiguating it from the other half-dozen similarly-named, almost as long variables. At times I resorted to diff to verify that two variables were, or were not, the same one. Good times.

Re: Not knowing the /proc file system

#79

Post by mixmastamyk »

mauvehaus wrote: post #3
9dev wrote: post #2

Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?

It's party cultural. Look at the NT kernel mode documentation. In the Windows side of the world, it's perfectly normal for functions to take eight to a dozen parameters, each with a fairly verbose name. Example: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

The early nineties were a lot different than the early seventies. One poster already mentioned the difference between paper and "glass" teletypes.

Re: Not knowing the /proc file system

#80

Post by toast0 »

spacechild1 wrote: post #75
mananaysiempre wrote: post #40

> I’m using a custom function for reading lines from a file. [Listing: fgetLine()] It’s probably easier to just use getline(), it does basically the same thing and is in POSIX.1-2008[1]. [1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

AFAICT, getline() is not available on Windows, neither with MSVC nor MinGW. The actual solution is to use C++ instead of C :)

That shouldn't be a big deal for accessing the /proc filesystem as that's also not available on Windows, AFAIK.
Post reply on HN