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

Bored? How about trying a Linux speed run?

rachelbythebay.com

Post reply on HN
Print view View original

261–270 of 284 posts

Re: Bored? How about trying a Linux speed run?

#261

Post by anthk »

chrisbroadfoot wrote: post #247
anthk wrote: post #108

Earlier quoted context omitted.

Or just get a static tar and xz static build, they must be somewhere. Better: busybox build. It already has tar, xz and wget. You just need to compile a simple HTTP client, or better: find a gopher mirror. Bare netcat would work against that. gopher://ftp.icm.edu.pl:70/1/vol/rzm6/busybox/binaries With NetCat: echo vol/rzm6/busybox/binaries/1.21.1/ | nc ftp.icm.edu.pl 70 echp vol/rzm6/busybox/binaries/1.21.1/busybox-i…

> telnet, nc, ftp, ncftp, lftp, wget, curl, lynx, links? Luxury! Gone. No nc.

Ok, switch the C compiler to a Go one:

https://github.com/kisom/goat/blob/master/goat.go

Well, JK. A simple, braindead, ugly and fast netcat clone (client only) can be done in C in few functions.

Re: Bored? How about trying a Linux speed run?

#262

Post by Avamander »

jcranmer wrote: post #248
brobinson wrote: post #243

Earlier quoted context omitted.

Not necessarily a myth anymore, strangely. If you apt/rpm install something nowadays, it probably wasn't built with support for newer CPU instructions (AVX, AES-NI, sometimes even SSE4). -march=native is gonna have a much bigger effect now than stage 1 Gentoo installs did in the mid-2000s. (and, yes, I do remember waiting a full day for KDE to compile) https://web.archive.org/web/20080704112619/http://funroll-lo...

> -march=native is gonna have a much bigger effect now than stage 1 Gentoo installs did in the mid-2000s. Actually, probably quite the contrary. All x86-64 chips are required to support SSE2, which lets you use SSE for floating-point instead of x87 floating-point, which is a big speed win. But the newer extensions are specialized SSE instructions, which generally require manual use of instructions to utilize; special…

But what about other SIMD extensions, are really all packages distributed with the expectation that for example SSE5 and similar are supported?

Re: Bored? How about trying a Linux speed run?

#263

Post by bear8642 »

NikolaeVarius wrote: post #215
Kaze404 wrote: post #177

Earlier quoted context omitted.

How do you stop someone from memorizing the run? Better yet, how do you stop yourself from doing so?

A large brick wrapped in a slice of lemon

Also known as a Pan Galactic Gargle Blaster

Re: Bored? How about trying a Linux speed run?

#264

Post by anthk »

datenwolf wrote: post #232
anthk wrote: post #108

Earlier quoted context omitted.

Or just get a static tar and xz static build, they must be somewhere. Better: busybox build. It already has tar, xz and wget. You just need to compile a simple HTTP client, or better: find a gopher mirror. Bare netcat would work against that. gopher://ftp.icm.edu.pl:70/1/vol/rzm6/busybox/binaries With NetCat: echo vol/rzm6/busybox/binaries/1.21.1/ | nc ftp.icm.edu.pl 70 echp vol/rzm6/busybox/binaries/1.21.1/busybox-i…

> Or just get a static tar and xz static build, they must be somewhere. That is, that you can find them in an uncompressed form. If you fees adventurous you can probably coax the compressed data somehow through the bootloader decompressor, or the xz or deflate implementation found in the Linux kernel. Unfortunately these days modules tend to be compressed as well, but it should be possible to convice libdl to open a…

Busybox has these in binary form, in either HTTP/FTP/Gopher servers or who knows which other protos. Pick your poison. Once you set a barebones connection to a gopher server from stdin using a little of C socket establishing code, you can just send the commands to fetch the binary, redirect it to a file and chmod(2) +x it with ease.

Re: Bored? How about trying a Linux speed run?

#265

Post by jcranmer »

Avamander wrote: post #262
jcranmer wrote: post #248

Earlier quoted context omitted.

> -march=native is gonna have a much bigger effect now than stage 1 Gentoo installs did in the mid-2000s. Actually, probably quite the contrary. All x86-64 chips are required to support SSE2, which lets you use SSE for floating-point instead of x87 floating-point, which is a big speed win. But the newer extensions are specialized SSE instructions, which generally require manual use of instructions to utilize; special…

But what about other SIMD extensions, are really all packages distributed with the expectation that for example SSE5 and similar are supported?

Most of the SSE3, SSSE3, SSE4.1, and SSE4.2 (there is no SSE5 in any released processor) instructions are not particularly feasible to be used by automatic vectorization, being mostly horizontal vector optimizations or some oddball instructions that are pretty task-specific (hi, PCMPESTRI). You might see them come up in SLP vectorization, but my last experience with LLVM's SLP vectorizer is that it does a poor job of taking advantage of these kinds of instructions anyways.

For hot kernels (say, memcpy), it is definitely the case that many projects have implementations of several different varieties of these, and use the version best suited for your current architecture. See https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86... for the different variants of common functions in glibc.

Re: Bored? How about trying a Linux speed run?

#266

Post by teddyh »

abecedarius wrote: post #244
teddyh wrote: post #198

Earlier quoted context omitted.

The shell would then have to also have a mechanism to pass all local state such as command history, local non-exported variables (including shell functions), open file descriptors, currently running jobs, etc. to the subshell.

We're talking about bootstrapping to more usable tools, not about whether this hack fully replaces the standard feature. 'cd' certainly comes before command history, for example. Incidentally you could take the same approach to some other shell built-ins, like redirection. Instead of `cat foo >outfile`, define a program named '>' and then say `> outfile cat foo`. (Assuming the initial bare-bones shell parses '>' as j…

There are a couple of problems with that design. Firstly, if the program crashes for any reason, you don’t have a shell to fall back on, unless you run the debugger as your shell, like ITS did back in the 1960s. Secondly, you can’t have more than one job running at the same time, or even any suspended jobs. And even ITS (again) has subjobs.

Re: Bored? How about trying a Linux speed run?

#267

Post by archseer »

toast0 wrote: post #225
archseer wrote: post #98

Earlier quoted context omitted.

Synaptics is deprecated with no maintenance. > The xf86-input-evdev driver is in maintenance mode at this point. The last commit was in May 2018 and, since the 2.10.0 release four years ago, there have been a total of 19 commits. It is still shipped in RHEL 8 in order to support "crazy devices" that don't work otherwise. Similarly, xf86-input-synaptics had a 1.9.0 release in 2016 and has had nine commits since. It is…

If the devices aren't changing, and the interface isn't changing, why should the driver change? Working software should keep working.

Because it became a burden to maintain. https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-...

> In the old synaptics driver, we added options whenever something new came up and we tried to make those options generic. This was a big mistake. The driver now has over 70 configuration options resulting in a test matrix with a googolplex of combinations. In other words, it's completely untestable. To make a device work users often have to find the right combination of options from somewhere, write out a root-owned config file and then hope this works. Why do we still think this is acceptable? Even worse: some options are very specific to hardware but still spread in user forum examples like an STD during spring break.

Re: Bored? How about trying a Linux speed run?

#268

Post by abecedarius »

teddyh wrote: post #266
abecedarius wrote: post #244

Earlier quoted context omitted.

We're talking about bootstrapping to more usable tools, not about whether this hack fully replaces the standard feature. 'cd' certainly comes before command history, for example. Incidentally you could take the same approach to some other shell built-ins, like redirection. Instead of `cat foo >outfile`, define a program named '>' and then say `> outfile cat foo`. (Assuming the initial bare-bones shell parses '>' as j…

There are a couple of problems with that design. Firstly, if the program crashes for any reason, you don’t have a shell to fall back on, unless you run the debugger as your shell, like ITS did back in the 1960s. Secondly, you can’t have more than one job running at the same time, or even any suspended jobs. And even ITS (again) has subjobs.

> Firstly

If your shell crashes, same problem. And the shell is a bigger program. This issue seems pretty orthogonal. Again, I was never saying this is a better way to design a shell for everyday use, unless maybe with a lot of complementary design decisions changed to go with it.

> Secondly

Why couldn't you spawn jobs like `& do-the-job` in this style? Admittedly I don't remember much about Unix job handling.

Re: Bored? How about trying a Linux speed run?

#269

Post by archseer »

pierrebai wrote: post #171
archseer wrote: post #99

Earlier quoted context omitted.

People always complain about this, yet nobody contributes: http://who-t.blogspot.com/2019/10/libinputs-bus-factor-is-1....

Bus factor is irrelevant. It's a concept that basically boils down to "people would not be smart enough to understand the code unaided". This is plainly wrong. I speak from experience of diving into some horrible code base. It also assumes that reproducing the functionality from scratch would be hard. Looking at all the reimplementations of A where A is one of unix, X, web browser, network stack, SQL database and oth…

My point here was that it's really easy to complain about the touchpad driver but it takes a lot more effort to actually go and write the code. There was some effort last year: https://gitlab.freedesktop.org/wbharding/libinput/-/commits/...

I also don't see bus factor the same way you do. People can be smart enough to understand the code, but unless someone actually goes and actively takes up code maintenance the project will slowly fade and disappear (for example the synaptics driver that libinput replaced https://github.com/freedesktop/xorg-xf86-input-synaptics/com...).

Re: Bored? How about trying a Linux speed run?

#270

Post by archseer »

archseer wrote: post #267
toast0 wrote: post #225

Earlier quoted context omitted.

If the devices aren't changing, and the interface isn't changing, why should the driver change? Working software should keep working.

Because it became a burden to maintain. https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-... > In the old synaptics driver, we added options whenever something new came up and we tried to make those options generic. This was a big mistake. The driver now has over 70 configuration options resulting in a test matrix with a googolplex of combinations. In other words, it's completely untestable. To make a devi…

Also note that the libinput maintainer was also the last synaptics maintainer. https://github.com/freedesktop/xorg-xf86-input-synaptics/com...
Post reply on HN