/tech/ - Technology★

Can't you use a search engine, you subhuman?

https://www.startpage.com/do/asearch?cmd=process_search&cat=web&query=linux+traffic+graph&language=english&no_sugg=1&ff=&abp=-1&nj=1

https://www.dynacont.net/documentation/linux/network_monitoring/

bwbar sounds nice.

>>947990

>calls others subhuman

>can't even read

oh the ironing

Not impossible, but there's no easy way.

kde widget named network monitor

or try kcm nomad

>>948424

can they write to a database?

>>948432

Look into rrdtool.

>>947990

>bwbar is a small C-based program for Linux-based machines which produces bandwidth usage statistics for a network interface.

>network interface

>not process

Dumbfuck.

Nethogs.

>>947978 (OP)

Linux is the name of the kernel that Linus Torvalds developed starting in 1991. The operating system in which Linux is used is basically GNU with Linux added. To call the whole system “Linux” is both unfair and confusing. Please call the complete system GNU/Linux, both to give the GNU Project credit and to distinguish the whole system from the kernel alone.

The Linux answer to your question is /proc/net/tcp.

http://lkml.iu.edu/hypermail/linux/kernel/0409.1/2166.html

46: 010310AC:9C4C 030310AC:1770 01 00000150:00000000 01:00000019 00000000 1000 0 54165785 4 cd1e6040 25 4 27 3 -1

This is a perfect example of UNIX emphasizing human readability over computer efficiency. This line would use half as many bytes in binary, but you wouldn't be able to read it.

What is Unix doing with all that file space?  No don't
answer.  It is providing all sorts of accounting junk which
is excesive for personal machines, and inadequate for large
systems.  After all, any important file in the system has
been written by root -- terribly informative.  And all that
wonderfully descriptive information after lots of memory
consumed by accounting daemons and megabytes of disk taken
up by the various useless log files.

>>949104

>This is a perfect example of UNIX emphasizing human readability over computer efficiency. This line would use half as many bytes in binary, but you wouldn't be able to read it.

Are you supposed to write programs that are human readable also?

Actual network/embedded programmer here who has implemented this kind of thing a few times. The lazy way on Linux is to add rules for the traffic that match in the mangle table and just read out the packet/byte match counters that netfilter is already keeping track of for you. If pid matching isn't good enough, you can run the program in a different netns and put the rules on a veth you use to route it to the main namespace to catch "everything". Beware of systemd services that let a namespaced program ask a non-namespaced service to do a HTTP request..

At a high rate, per-packet stat collection is surprisingly tricky to do without causing severe contention (this is actually why veth devices used to be so fucking slow) and the netfilter guys have already done the work. If you need more detail you have to write a kernel module that plugs into netfilter and you get the enjoyable experience of having to do major rewrites every year because the kernel guys are physically incapable of just leaving things alone. I used to store info in the route cache and then one day in the 3.x series they just totally removed the route cache. Fun.

>>949129

>>949154

Readability doesn't have to come at the cost of computer efficiency at all. Hardware used to be built to make what the user wants to do faster (CISC) instead of building what was fast for some C compilers at the time (RISC). Linux gives you a mix of hex and decimal numbers that's slow for computers and hard for people to understand.

A lot of work on programming languages outside AT&T was about making programs faster and easier to read too. Control structures have a big impact on speed and readability. The RISC trend reversed all the work on improving computers for people because they created the myth that faster for machines and better for people are opposites, which is true on RISC, instead of the truth that computers and operating systems are made by people and can be as user-friendly, secure, and reliable as their creators want.

>In another article WD writes:
>|> [of VMS]
>|>   I sure hope so. Any o/s which puts file types in the o/s
>|> instead of the program is really creating problems for the
>|> user, and I find that more of a problem than the user
>|> interface. If programs really want a "$ delimited left
>|> handed nybble swapped hexadecimal" file type, let it be
>|> done in the program or shared library, and not at a level
>|> when all user-written file transfer and backup programs
>|> have to deal with it. As my youngest says "yucky-poo!"

Huh?  Let's think about this.

Tighter integration of file types to the OS are not a
problem.  In my experience, UNIX offers the weakest file
maintenance offerings in the industry, save for MS-DOS.  In
using Tandem Guardian and VMS I've found that ultimately,
one could:

* Back up files.

* Transfer files.

* Convert files.

...much more easily and safely than with UNIX.  Yes, it was
between Guardian or VMS systems but instead of going into an
"open systems" (whatever THOSE are) snit, read on.

RISC is a shit design, anyway. EPIC is better at the hardware level and we're only not using it today because compiler writers weren't able to harness the power. Part of that is that the difficulties compiling C due to things like aliasing limiting the extent of optimization. Hardware that opens more opportunities for optimization is wasted when C compilers already hit the limit on x86.

>>949306

Pipelining isn't beneficial?

>>949582

CPU pipelining was first done on mainframes in the 60s, like the IBM System/360 Model 91. This paper was published in 1967.

http://home.eng.iastate.edu/~zzhang/courses/cpre585-f04/reading/ibm67-anderson-360.pdf

RISC is like UNIX and C culturally as well as technically. Load/store and fixed-length instructions didn't come from RISC, just like hierarchical file systems and text stream files didn't come from UNIX. They just happened to fixate on a few things other people already did that aren't particularly good at everything, but want to use them everywhere even though better alternatives exist. This is why solutions from the 50s and 60s like strings with lengths, array bounds checking, and integer overflow checks can't be used with C and why record files and good error handling can't be used with UNIX. This is the problem with both RISC and UNIX/Linux /proc files, which are much better handled as binary data structures (record files) than lines of text.

Subject: Wait, I Thought RISC Was A *Good* Idea

"RISC is to hardware what the UNIX operating system [sic] is
to software."

			SPARC Documentation, RISC Tutorial, page 2

Subject: The Emperor of China

Section 30.02 of _Unix Power Tools_ by O'Reilly & Associates says
    ... /ispell/, originally written by Pace Willison ...

but hey, I was there when Pace ported the ITS SPELL program
to C.  Sure I am grateful to have a few reminders (^Z is
another one) of bygone glories around, but let's give credit
where credit is due!  Legend tells of a Chinese Emperor who
ordered books burned so all knowledge would be credited to
his reign.  I guess the subsequent generation of scholars
were a lot like the Weenix Unies of today.