[ / / / / / / / / / / / / / ] [ dir / animu / hypno / leftyb / mde / mewch / nofap / pinoy / tingles ]

/tech/ - Technology

Winner of the 80rd Attention-Hungry Games
/otter/ - Otter For Your Soul

May 2019 - 8chan Transparency Report
Comment *
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Show oekaki applet
(replaces files and can be used instead)

Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 3 per post.

File: 90f7d54fcc98c0d⋯.jpg (104.31 KB, 1136x656, 71:41, Clipboard01.jpg)


Do you have a second to talk about terminal emulators?

Is there a reason not to use whatever defeault your distro comes with?

Are there noticable differences between different ones?

Which one are you currently using and why?





Used to be a yuge urxvt faggo but xfce4-term is the best I've used. Good balance of werks-n-features and minimalism.


xterm. Seriously.

No bugs, fast, works with everything, even has sixel support. It's the reference. Even on old systems the overhead it has compared to more incomplete emulators is not worth putting up with their problems. Use it with a bitmap font and that will be the fastest terminal emulation you can get.



                        Abandon All Hope, Ye Who Enter Here

This is undoubtedly the most ugly program in the distribution. It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014
subwidgets so that they could be used in other programs. We are trying to
clean things up as we go, but there is still a lot of work to do.



Yeah, it's a mess code wise, but it works and works fast. Compare st (which isn't well written either but meme here) to xterm in regards to speed. Hell, compare it to urxvt. xterm will come out on top.





Except urxvt is actually good


Why is the ancient terminal abstraction still a thing in current year?



Because making something better would require committing more resources than to just continue using the pile of shit that alreadt exists.

"If it ain't broke, don't fix it" is the real UNIX philosophy.

Gas all UNIX weenies tbh.




Is anyone seriously concerned with terminal speed?





>Alacritty is the fastest terminal emulator in existence. Using the GPU for rendering enables optimizations that simply aren't possible in other emulators.

Rust wins again over C/C++



Fastest at what?

>rendering optimizations

I don't even



At displaying gibibytes of text per second of course.



hey if it ain't broke, don't fix it


File: 2ae2a05d3efdcbd⋯.png (49.18 KB, 787x367, 787:367, nfs_terminal_edition.png)




My GPU is too weak for that. Too many pixels.


pseudo-realistic use of a fast terminal is games like Catacylsm DDA, they will genuinely lag in a slow terminal. Also I bet for half the faggots using gentoo here because of the meme, most don't realize that putting out all that compilation text actually slows down compilation. Yes, that's right, it's directly tied to the terminal speed. Try a faster terminal, or better do it --quiet

alacritty is a fucking mess written by people who don't know what they're doing, also it pulls like half of all rust libraries in existence in, I don't even wanna know how unsafe that is. All it takes is one compromised library.



Why don't you fix it yourself if it bothers you that much?



>posting 2 years old disinfo

Found the anti Rust shill



>alacritty is a fucking mess written by people who don't know what they're doing


>I don't even wanna know how unsafe that is

About as unsafe as writing C/C++.




Looks like he wasn't faster than urxvt until Sept 2018. So go fuck yourself tard.



>Looks like he wasn't faster than urxvt until Sept 2018.


>So go fuck yourself tard.

The anti Rust shill is immunized against all dangers: one may call him a LARPer, nodev, ctard, UNIX weenie, it all runs off him like water off a raincoat. But call him an anti Rust shill and you will be astonished at how he recoils, how injured he is, how he suddenly shrinks back: “I’ve been found out.”



>about as unsafe as c/c++

right: per line of code




fucking hell this nigger doesn't even read his own garbage.



I read it. I'm just not sure that you have the mental capacity to understand was was written though. Alacritty v0.2 added scrollback support. This means v0.1 didn't have scrollback support.

If you wanted scrollback in Alacritty v0.1 you had to use tmux. So of course alacritty v0.1 loses against urxvt in a scrolling benchmark.

You anti Rust shills seriously are fucking retarded.


File: 7bd98011b969067⋯.png (16.29 KB, 883x495, 883:495, suckless_larpers.png)


That's worthless then. Response speed, now that's a topic for discussion. Apparently, xterm is the fastest in that regard.



fastest response is direct console without X in between, you'll never get faster and it is kind of noticeable. I'm not even one of these retards that thinks he can notice 10 ms differences or hear the grass grow, but it does feel different typing there somehow.



>terminal latency

What about keyboards though?




>terminal for the White Man



>my ebin shitpost is so ebin I have to redtext and greentext at the same time to show everyone how ebin my shitpost is


File: dcc5288191317f1⋯.jpg (96.69 KB, 710x532, 355:266, DeQcLi6WsAANp5u.jpg)


>being so Jewish and having nothing to say



>calling everyone a kike




That's right kike. It seems mentioning White Man triggered you.


File: f2c72aa079eecf5⋯.jpg (2.29 MB, 575x3110, 115:622, 56%.jpg)



oh so he put it 3rd even though 0.1 couldn't even compete. Yeah sure thing faggot I'll trust your "benchmarks" now.



What you're saying makes no sense.



Scroll to the comments, st is the fastest if you bump some variables in its config.h.



xfce4-terminal is great.


>overclocking a terminal emulator


Does a shell run directly within a terminal emulator, or is there yes another layer in between?


>whatever default your distro comes with

will not apply to most people here I'm guessing. I use kitty (also a GPU meme terminal emulator)--not because I find it superior to any other terminal emulator in terms of functionality (though I prefer my terminal UIs without extra menus and buttons), but just because it works on Wayland. It would probably run faster without its windows/tab shit but I don't give nearly enough of a fuck to go hunting for another terminal that works.



>using software by a pajeet that doesn't understand how callbacks work


also there is this: https://lwn.net/Articles/465311/



Inside of an X session runs a terminal emulator (such as xterm), inside of which runs a virtual (pseudo)terminal (such as /dev/pts/0), inside of which runs a shell (such as /bin/bash), inside of which runs a consol program (such as /usr/bin/top).



Using callbacks to model the passing of time is for pajeets



Urxvt renders fonts incorrectly. I have no idea why and honestly don't give a shit why. A terminal that can't render text correctly is a failure.

Honestly they all suck. I use kitty at the moment but it happens to be written by a pajeet with an attitude worse than poettering.



>direct console without X in between

I've noticed the consoles under GNU/Linux and OpenBSD don't implement many important ECMA-48 control functions that other terminals do. Examples include SCROLL UP, SCROLL DOWN, and CURSOR CHARACTER ABSOLUTE. These control functions make the screen seem to scroll up, scroll down, and move the cursor to a point on the current line, respectively.

The last can be discarded, but the former two are very important and I find it unacceptable that those consoles don't implement them.

If I'm wrong, I'd appreciate being corrected, but I've done my own testing and asking around and it seems these were simply never implemented.


I just use st.


>easy to maintain

>only has the features i use and want i to have

>good unicode support

>truecolor support

>fast at rendering images (i use terminal file managers)

>customizable in every aspect conceived

>written in c, a language i happen to program in.

>overall small footprint

>don't need tmux to tab since my wm does this

Urxvt kind of lagged behind on verbose output, had subpar unicode support and did not support trucolor. Still, it is a pretty decent terminal emulator.

I would recommend st for minimalists, urxvt for functionalists and xterm for maximalists. Used a lot of emulator, and these still stand out as my standard choices.


How do I make my own?


I feel like there's still no AAA terminal available.


I use st because it's small and sanic fast and does what it needs to do

if I want a crufty terminal for some reason (like I need to cuntpaste a lot of stuff via ssh) I keep terminator around just because of the in-window-tiling but it's a slow cunt despite it's size (because python)



Just read the xterm souce code.



Well, urxvt lacks some stuff too. It doesn't support the invis termcap while st does.


I use terminology because it looks nice. Go ahead and bully me.


File: 6977af9d91e515b⋯.png (814.94 KB, 1123x750, 1123:750, cool_retro_term.png)

These retro feels are so comfy.



I just tried it, it has some neat stuff. I didn't find a way to save sessions though, like to remember splits.




What program is that?



<he can't read the image's name

Are you illiterate?



File: 76718ba0d7f4442⋯.png (196.05 KB, 825x776, 825:776, konsole yuk.png)

File: 5291ce3d2d469a0⋯.png (4.13 KB, 486x347, 486:347, xterm.png)

File: 7a22f5ae987d6a9⋯.png (83.13 KB, 746x732, 373:366, window manager tweaks.png)



I was actually going through a bunch of terminal emulators earlier today.

Here are my unsolicited reviews:

<- The gnome-terminal is awful - I can't even transparent anymore with it. they ruined it.

<- Sakura kind of sucked because it didn't have options that I wanted

<- Terminator would be good if they didn't have that extra bullshit below the top margin - that whole block of nothing useful

<- Guake was unmoveable - it's stuck at the top of the screen. I couldn't drag it away from the top of the screen. wtf? Fukin stoopid

<- Xterm is unusable - a total joke unless your gui display resolution is 800 x 600

<- Konsole sucked. I couldn't remember why. I just didn't like it. It didn't split the way I like it and there's this big block at the bottom that all it says is user : bash

I wanted to make a transparent background

it wasn't happening through the terminal settings

so I had to go into 'Window Manager Tweaks,' then enabled display compositing and it worked fine in xfce4 (and everything else except for gnome-terminal)

mission accomplished with maximum distractions



found it in the test repositories

will post some moar screenshots of that in a fecund second


File: 004fff3ad7bb0db⋯.png (2.85 MB, 1920x1080, 16:9, cool retro term 1.png)

File: 627510bb63031cb⋯.png (2 MB, 1920x1080, 16:9, cool retro term 2.png)

File: 068bfd02af1967b⋯.png (1.93 MB, 1920x1080, 16:9, cool retro term 3.png)



it's cool and edgy and all that, but I can't work in that.


File: 36b5cbc8bf7d55f⋯.png (1.89 MB, 1920x1080, 16:9, cool retro term 4.png)


File: 3e48cc4128a2e33⋯.png (70.41 KB, 739x487, 739:487, terminator.png)

File: 15b273a1d027d2a⋯.png (16.48 KB, 676x367, 676:367, gnome terminal.png)



Only hipsters who want to look 1337 and Kewl and don't know how to do anything other than install """Linux""" use this shit.



Wow, this dude is an ass.




your dubs confirm



>November 2, 2011






oh yeah it's probably shit allow me to use bloated modern garbage



those were all my posts though with all the screenshots.

I was really annoyed with all those term emulators btw and went straight back to xfce4



Found the rust shill



Found the rust shill






xfce4-terminal is really nice. Idk about how lightweight it is though.



I can't tell if you're calling "Cool Retro Term" bloated or calling other things bloated.

If it is the latter, you're retarded


File: 2695c52c9381b93⋯.gif (196.93 KB, 220x220, 1:1, for real.gif)




what? 3 bytes extra worth of memory?

come on

Yeah, I suppose your'e right

my processor might not handle it

it's from 1985


urxvt cause i donno why not. it seems simple enough, and it provides a bg daemon which makes me feel smart


Most of you larpers probably don't even know you can set your own colors and fonts in pure linux terminal. I converted the fonts from int10h.org to .psf. They are incredibly readable, even on modern screens. I even made a batch of size x 2 fonts, they should have a nice size even on 4k.

The more steps you put between you and the console, the slower it's going to be. No matter where, always use bitmap fonts, never use these modern meme anti-aliased vector fonts, they're incredibly slow in rendering and because of the complicated way they're rendered, they're pretty much doomed to never line up pixel perfect. (try drawing boxes with the box characters with a font like Monaco or Iosevka, I'll wait, it'll look like shit) This is only possible with bitmapped fonts.

If you work directly from the linux console, tools like screen give you additonal VT100 control functions and things like scrollback. With screen you can also share sessions. I connect screen to a vt and use it to make printouts to an ereader with eink screen which is hooked up via usb.

There's so much possible without ever using a terminal emulator, there's really no reason to use one.


File: e6f9c954bc73a4b⋯.png (24.49 KB, 964x580, 241:145, ladder.png)


Linux console is a terminal emulator though. It's a virtual thing, instead of hardware device connected over serial port like was commonly used in the 80's and prior. Those terminals didn't emulate anything, they had their own set of escape codes for doing stuff like moving cursor around (assuming a glass terminal here, not a hardcopy teletype).

Pic is screenshot of LADDER.COM game for CP/M, in configuration mode. If you select the last option, it asks you to input the ASCII code sequences for clear screen, direct row/column addressing, and so forth. that your terminal uses The other choices are all commonly available (back then) real hardware terminals. The Linux console isn't like this at all, it was never available in actual hardware form, just some code in the kernel to drive the console, and it pretty much emulates VT100/ANSI more or less.



True, that was a mistake on my part. With emulator I meant the X-based programs. They all have in common that they're a lot slower. They pretty much have to be as you have more layers in between what you press on the keyboard and what appears on the screen. If that slowless actually matters or not is the other question.

I find the virtual terminals in linux just work better and seem more compatible for my usage scenarios. The one that comes second in X is xterm. Everything else had some degree of problem for me, because of overwhelming slowness or incompatibility. Especially if you add more modern fonts into the mix in X.

There are also framebuffer terminals, but they all had in common for me that they're very slow, even though they have some nice extras. (YAFT for example has 256 colors and sixels)



>works with everything

sometimes i copy something in a program and i try to paste it in xterm with shift+insert and it doesn't paste what i had copied and that's why i always use konsole.


I'm a terminal noob, anyone want to spoonfeed?

>why care about speed, it's already fast on a modern computer?

>why use splitting when you can just open it multiple times and use your wm to "split"

>why things like ctrl+c ctrl+v don't work

>why transparency is a big deal isn't it harder to read

>why some terminals take a long time to launch (sometimes 1 sec)



just use tmux to split



>why care about speed, it's already fast on a modern computer?

Probably just autism, nobody notices the sub ms latency

>why use splitting when you can just open it multiple times and use your wm to "split"

If you use something like i3wm sure, but in a floating window manager it's just a lot faster to navigate between terminal windows with the keyboard, doesn't matter much if the emulator does that anyway since tmux is superior

>why things like ctrl+c ctrl+v don't work

Because those keybinds already have functions in the terminal, use ctrl+shift+c/v

>why transparency is a big deal isn't it harder to read

Not really, if you don't have a busy background and don't set the transparency level up that high

>why some terminals take a long time to launch (sometimes 1 sec)



People buying into the speed meme are being baited. Most terminals are not bloated enough to actually be slow.

The real problem with terminals is how many stupid edge case failings they have. Try getting a terminal that displays UTF-8 correctly including CJK. Then one that doesn't fuck up vim in some way. Then one that doesn't fuck up tmux. etc.

It's really the perfect example of how shit everything is when people just go crazy and reinvent the whell for no reason over and over.




>Why care about speed, it's already fast on a modern computer

One of my computers is a Chromebook and the Linux terminal runs noticeably faster than any terminal emulator. Aside from that particular case though it probably doesn't matter.



>It's really the perfect example of how shit everything is when people just go crazy and reinvent the whell for no reason over and over.

Xterm is an excellent example of this. I'm disgusted with using Ncurses in a Common Lisp program, so I wrote my own terminal abstraction library; the intent was to permit me to manipulate a terminal at a high level using a lower library I've also written.

Here is the main page: http://verisimilitudes.net/2018-04-04

Here is the program itself: http://verisimilitudes.net/acute-terminal-control.lisp

I'll just be showing some of my comments.

With regards to extended colors, defined in ISO 8613-6 and how Xterm and others don't implement them correctly:

>The NIL should specify the default color space identifier specified in ISO 8613-6.

>Unfortunately, giving a default value for this isn't parsed correctly by any terminal emulators, it seems.

>So, it is omitted for now.

>It will otherwise shift the colors under many implementations.

>You'd expect something as simple as this to be done correctly, but it's not.

>See page 49 of the standard; if 2, 3, or 4, there's a second parameter followed by more.

>That second parameter is the color space identifier, followed by the actual color integers.

>This second parameter is erroneously ignored, however, in a way that probably won't ever be corrected.

>I'll be submitting bug reports to the terminal emulators.

>So, perhaps I'll be able to send the correct sequence in a year or two.

>The same page specifies that character #x3A, colon, may be used to separate these parameters.

>Since that's a ``may'', the semicolon is used; at least this simplifies the program.

>Some terminal emulators don't parse the colons correctly anyway, but I don't care about that.

>If you'd like to learn more about the blatant violation of standards, read The UNIX-HATERS Handbook.

I have two functions, READ-EVENT and READ-EVENT-NO-HANG, that are intended to allow me to read events from the terminal at a high level, distinguishing between a mouse action, a function key, and normal character input, among other things.

The ECMA-48 standard defines a FUNCTION KEY control function and this scales to as many function keys as possible, but Xterm doesn't use this. Instead, it has multiple, incompatible schemes.

>As we already know, xterm is very poorly and barely designed.

>Xterm likes to make its own standards for things, even when standards already exist.

>Xterm then likes to implement real standards incorrectly.

>Why use FUNCTION KEY when you can use SS3?

>Xterm is like a retarded child and should be put down.

>Here's the pattern xterm uses for function keys one through twelve:

>SS3 P SS3 Q SS3 R SS3 S

>CSI 1 5 ~ CSI 1 7 ~ CSI 1 8 ~ CSI 1 9 ~

>CSI 2 0 ~ CSI 2 1 ~ CSI 2 3 ~ CSI 2 4 ~

>Simplicity at its finest, you see.

>With any luck, this garbage can be removed soon.




Xterm has multiple broken and incompatible mouse reporting modes and none of them are a proper control sequence and so none of them can be parsed nicely by a generic parser.

>Now, if the sequences sent were sane, I wouldn't even need this COND.

>Xterm sends CONTROL SEQUENCE INTRODUCER, but with characters other than parameters immediately following it.

>I can only figure this is to aid parsing by allowing one to quickly figure out what the control sequence (if you'd still call it that) is.

>While that does aid parsing if you just want a poor job, it actually complicates comprehensive parsing, like this.

>I can't just have a loop reading in parameters and then at the end matching a single character or two to see what it is.

>I can't just then check to see if the number of parameters read in is correct for the corresponding identity.

>I can't just have a limit to keep out of an infinite loop; three would be a good limit here, currently, since nothing supported needs more.

>Instead, I need a different case for each and then I can do the parsing, which is still followed by other identifying characters.

>So, this could've been a beautiful function, I think, but the horrible design of xterm prevented that.

>Instead, this is a purely practical machinery and I can only think about how nice it would've looked if things hadn't been designed by idiots.

I've had a good deal of unpleasant interactions, because not only do these cretins not implement the standards correctly, they don't even know most of the standards they're implementing; they simply do whatever Xterm does. I spent too much of my time checking if ISO 8613-6 colors were the standard actually being implemented; I believe they are and it's simply done incorrectly. I submitted a lazy patch to the st developers and raised these issues, but no one really cared; I've similarly had no real luck with other terminal developers; I suppose the thinking may be that it would break too many programs, so we should all just use a subtly incompatible form of the standard instead. Where have you seen that before?

The only reason terminals are still popular is because everything else is even worse and now you can recognize that even that is truly awful and managed by idiots. I could write a much longer series of posts about this, but I won't.





pick one nigger




when we actually used those kind of screens, if we saw a screen like that we'd throw it out. Dial down those settings to achieve normality and it becomes a beautiful time machine into the past.


comfier settings, though too much bulge (the screens with that amount of bulge didn't use scan lines, and came earlier (late 70s) than those (mid 80s), and too much glare/halo on the letters.



They're all shit implementations of a shit concept. Right now I'm using mrxvt because its the only one that doesn't have a fuckton of input latency and other AIDS. I think it has an unpatched vuln but I rather kill myself at this point than play around with other terminals again.


I really don't miss CRTs, they gave me eye cancer. The only nice thing they had was this slight glow to everything, but tbh that probably caused half of the eye cancer. I have a used POS (Point-Of-Sale, not Piece-Of-Shit) 14" LCD screen here that does a similar glow because it has a vandalism-proof front that glares a lot. It has a CCFL backlight.

Everyone says LED back-light is the best and for power consumption I bet that's true, but even the highend LED-backlight screens I've seen are still significantly bluer than CCFL backlight ones.

The nicest for the eyes though is eInk. I have a 13" eink android tablet I use with Termux and screen as sort of secondary screen. Thing was crazy expensive. Sadly there's not a single solution on the market re: eink screen that doesn't suck balls. It's all the finest of chink engineering.

An OLED screen for a text based console would probably be amazing though, but they don't exist at usable sizes.



Examples of such incorrect font rendering?


>>1022144 (checked)

I personally like GPM myself for some things but I rarely use it.


>terminal emulator speed

Damn, this is life changing, now I can update my packages in 10.255 seconds instead of 10.26 seconds because there will be slightly less delay imposed by the terminal emulator, thanks /tech/.




a meme until you use terminals in fullscreen or a tiling manager, it helps break up the completely black terminal so there's a bit of noise on the screen, completely subjective and if not pseudo at worst


extremely useful for floating window managers and/or the user hasn't learnt tmux/screen

>why some terminals take a long time to launch

combination of bloated shell (sh, dash, bash, fish, zsh, etc.) and blaoted terminal emulator

speed is a bit of a meme but could be a huge difference and keybindings because ctrl+c kills the process, so some sane defaults have shift+ctrl+c



>Terminator would be good if it didn't have the extra bullshit below the top margin-

it's tucked away in the gui options and you can disable it, it's bloated but it werks


completely missing the point, it's in the name



If you're compiling stuff (i.e. Gentoo) the speed difference can be quite noticeable



>a readme from literally decades ago



>a terminal emulator from literally decades ago




>extremely useful for floating window managers and/or the user hasn't learnt tmux/screen

Which is bloat since those multiplexers exist. Look at a dvtm/abduco for something better.

>bloated shell (sh, dash, bash, fish, zsh, etc.)

Are you retarded? sh is a standard, not an implementation and how is dash bloated?


Latency, not throughput.


Use parallel jobs, nigger.


File: fafdb5e9f2bce2f⋯.jpg (89.62 KB, 640x589, 640:589, Amiga-Workbench_zpsutk6gcx….jpg)


It probably means screen is malfunctioning. I had an small amber CRT that I picked up in '97 that was old as fuck and started doing wonky shit and then it just died altogether.

But good CRTs were pretty smooth and stable, even if the dot pitch might sucks ass in some cases, but was still good enough for low resolution like the old computers used. Actually I even had my Amiga 500 hooked up to a 19-inch TV for several months, and it was fine that way. Just had to set Workbench to 60-columns instead of 80, then it was readable. I even used Deluxe Paint like thata and it was fine. The Commodore 1080 monitors were a lot nicer though.


File: 3b687e81db59ebd⋯.png (280.45 KB, 2736x1744, 171:109, wsltty.png)

Here is my setup. The terminal emulator is WSLtty, running on Windows 10, using the Windows Subsystem for Linux + Ubuntu. The font is Fira Code, which has neat programming ligatures and is already patched with powerline symbols. The programs being run are tmux for multiplexing the various shells, neovim for editing, and bash for the shell.



>windows 10

>linux subsystem

but why



Maximum Pajeetness


File: 2506967c7e6ba4c⋯.png (433.18 KB, 773x566, 773:566, wut.png)


><- The gnome-terminal is awful - I can't even transparent anymore with it. they ruined it.

Gnome Terminal can transparent.



>Use parallel jobs

lol you think I don't?



Well, why would you complain about terminal output if you do?


In Nano, how can I get control backspace binded? I want it to cut one word left like in normal text editors, but it doesnt want to recognize it. Control P works, for example, but that isnt very intuitive. Others suggested using ^?, ^h, and ^H, but none have worked. Anyone know? I got the syntax for lua to work, and its comfy. Just doing casual coding.


File: 4d37c6292c46a70⋯.mp4 (8.03 MB, 1280x720, 16:9, out.mp4)


>when we actually used those kind of screens, if we saw a screen like that we'd throw it out. Dial down those settings to achieve normality and it becomes a beautiful time machine into the past.

I get angry when people emulate defects as if that's what displays looked like then. But worse is when they emulate a fucked up calibration.

Every monitor I ever owned let you calibrate the shape so that it could look more square. Not that they came from the manufacturer looking bad, but even if they did it took you 2 seconds to fix it.

I don't care how thick and bowed your glass is, this was always fixable.

I wonder how people are going to interpret LCD screens of today in 20 years. Probably assume that dead backlights, dead pixels, color mistakes, and 24hrtz was standard.



>this is what gaming has LITERALLY become

sage because powershell is master race



yeah sh and dash isn't bloated, but is an example of a shell.



>but why

I was Linux-only for 8 years, anon. I don't hate myself anymore.



Retro games in 50 years will have deliberate dead pixels and screen tearing.



Nobody cares about your realism shit you fucking autists. It's just a meme, people want an idealized version of the thing, not the whole thing warts and all. Who wants warts?

Do you also complain that 80s stations play only the good songs from the 80s, and that movies make characters seem more interesting than they would be irl?



Are you confused? Read the post again.



I've been using urxvt in daemon mode for a while now. It's reasonably fast and lightweight, and works fine for me.

I tried st but I didn't like it. Lack of scrollback alone makes it not worth it, not to mention that in the end, it wasn't noticeably faster or lighter than urxvt.

>use tmux for scrollback

tmux is good for remote sessions, but it's effectively useless locally if you're already using a tiling window manager. And no, the console is not an option for me, as I'm currently working with graphical programs as well.



I'm using st because unicode works great & it's good with Ranger image previews. Also I like suckless.


File: a6e2b1685fb314a⋯.jpg (102.93 KB, 470x355, 94:71, nerd.jpg)




Of all the names this could have been called, it got called one of the stupidest names you could think up. Cool-retro-term, what were they thinking?



I can only read that in my head with his voice.



man 1 patch, retard. And urxvt lacks the invis termcap, it's retarded.



<And urxvt lacks the invis termcap, it's retarded.

Literally a non-issue, I already use unclutter anyway.

Does st have a patch for it? Isn't it bloat for a terminal emulator to have this?


File: 569e787e4d709c1⋯.jpg (24.65 KB, 255x255, 1:1, 1445379315046.jpg)


>renders fonts incorrectly

Works for me, including font-fallback feature

>URxvt*font: xft:Screen:size=12,xft:terminus:size=12


st. It's fast enough. But still not as fast as just using the TTY. I wish I was less dependant on xorg and could use the tty more often, fucking webshit.



>just using the TTY

You mean what by this, just using the getty consoles, preferably without framebuffer but just in pure text mode? They are "virtual terminals" too, a true teletype would be something like an actual VT100, so what's the difference in the end if it's pure text getty, framebuffer getty, or a xorg emulator like xterm etc.?


What is the best terminal multiplexer? screen? tmux? how to get buffer scrolling (shift-pgup/pgdn) work properly in screen?



And why do only modified versions of screen (like the ubuntu one) support vertical splitting? It seems that with widescreens and all it would make a heck lot more of sense to split vertically than horizontally.






This is just a feature of newer GNU screen. It was a patch, before.


st (suckless terminal). No question.


>realize that less blaoted terminals have extremely smooth scrollback

although not sure if most /tech/ niggers have high refresh rate meme displays but it's pretty fucking epic


make sure you configure it to have render at a high fps


abduco works fine but dvtm has some of the weirdest bugs. Like, if you got a bunch of text scrolling pretty fast in one panel, it'll disturb the others, stuff like that. I use screen, no idea if tmux is better or not but I'm used to it.



how do you use shift-pgup/shift-pgdn in screen without it also scrolling the region boundaries? i.e. how to scroll the buffer of just the currently active region?



You go into copy mode(CTRL-A [) it lets you move the cursor freely around and scrollback with pgup/pgdown. with space you start selecting text, and space again stops the selection. With CTRL-A ] you can paste your selection.



*CTRL-a not A



Protip: being "nonstandard' and abandonware doesn't make something bad.



Still, missing an important termcap is embarassing. When using sh, you don't have read -p, so it's kind of needed.



The termcap database is obsolete crap anyway.


There's no reason not to use the linux' virtual TTYs directly, even if you want to run X apps. They can coexist and you can leave the X-Server running. With DRM, switching should be instant. (Dunno about nvidia, don't have nvidia hardware anymore, could well imagine that their blob drivers shit the bed there)

I admit It's such a minor thing but I like especially that the TTYs allow you to switch the cursor on the fly with escape codes, they even have the half-height cursors. I've used that a lot in vim to visually make a difference between modes. I just found that most stuff just works in the TTYs, while the different X-based terminal emulators always have something that doesn't. Xterm does work the best of them all though, it also supports sixels now, which basically allows you to print pictures right in the terminal. If the virtual-ttys would support sixels then they would be perfect, you can convert and write pictures directly to the framebuffer with ffmpeg, but it's just not as straightforward and needs some care taken so they don't get overwritten by text.



Terminfo has the same thing.



>the TTYs allow you to switch the cursor on the fly with escape codes, they even have the half-height cursors. I've used that a lot in vim to visually make a difference between modes

please elaborate



>make sure you configure it to have render at a high fps

Good point actually, never thought of that. Is it a patch or just a variable in the header files? All found on that was people talking about how they could possibly limit the frame rate, not increase it.

Smooth scrollback in a visual or in a sense of technical accuracy?



It's in the header files


/* frames per second st should at maximum draw to the screen */
static unsigned int xfps = 120;
static unsigned int actionfps = 120;

Mostly visual, and does reduce input lag if I recall, but that's in the realm of like milliseconds.



It's nice since I use a 144Hz monitor and most terminals only update at either 30fps or 60fps.



>There are two big problems with Gentoo Linux: first, most if not all Gentoo systems are completely broken (missing or mismatched header files, broken compiler etc. are just the tip of the iceberg); secondly, it should be called Gentoo GNU/Linux.

<For these reasons, it is impossible to support rxvt-unicode on Gentoo. Problems appearing on Gentoo systems will usually simply be ignored unless they can be reproduced on non-Gentoo systems.




Lmao no wonder urxvt sucks ass when compared to st or xfce4-term.

t. gentooman



What if I am using the BSD binutils instead of the garbage nigger utilities? Would it be Gentoo BSD/Linux then?



kek I thought the same thing. It's even in the urxct man pages, at page 7 if I'm not mistaken.

That link made me unironically switch to st.


The developer is probably a nigger. Also, the warning and the "Reporting bugs" section in its entry in the Gentoo Wiki: https://wiki.gentoo.org/wiki/Rxvt-unicode is gold.



>Also, the warning and the "Reporting bugs" section in its entry in the Gentoo Wiki: https://wiki.gentoo.org/wiki/Rxvt-unicode is gold.

For something so short, I bet it really stings. Lol.


If you want to use one machine as a terminal connected to the other's ttyS0, should the serial cable be straight-though, or a null-modem (i.e. crossed-over) cable?



normally you must have rx and tx crossed, not straight if you go for an UART connexion. but ...that's actually a good question I might want to check this, between an AS/400 and a Wyse term to me it's just a DB9 UART that's enough, then crossed or not ...

'Intresting thread; still want to use my 800XL as an ASCII term, I might find a way to wire this and find the adequate software.)


urxvt, of course.



GNU Emacs (M-x eshell) or xfce4-terminal.



>an os from literally decades ago



>Here's this terminal emulator written in rust; it's the fastest in existence because we say so and it's faster in the benchmark we wrote specifically to show that we have the fastest terminal which isn't questionable at all.

>by the way it's fast because it's written to use OpenGL and the GPU and not the CPU

>forget that the entire graphics stack is written in C/C++ and rust is doing nothing but interfacing with it

found the jew



mlterm + fix ur fonts fagit


Suckless is dropping xft support for dwm and dmenu: https://lists.suckless.org/dev/1902/33214.html

Is st next?


Good. Xft sucks. Use bitmap fonts like a white man.



The irony is that xfonts are an even worse mess than xft. I'll just switch to something that actually aims to be usable instead.



What is a "white man"?



If that means implementing a simple fallback mechanism, I'm all for it.


Fonts are so good that I often have no idea why characters won't display or what font I'm even using because I'm too scared that guessing will fuck up and I'll have crap fonts again.



st already supports fallback.



It doesn't, fontconfig does. If they remove it, they'll need to implement it themselves.


Termite is nice. Easier/cleaner to configure than .Xresources, has some cool built-in features like ctrl-shift-x to put hints by links so you can open them from the keyboard. Good for irc.




You. I remember you.

Is this xterm faggotry independent from the Linux tty subsystem? Or is that fucked too? What if someone were to make a new terminal emulator that implements the standards right? What if someone made a new standard?



Try some unicode shit. Screenshot the results.



>execute kitty

>GPU power usage jumps from 7 W to 30 W

GPU terminals are a mistake.



what the fuck is that janky ass font about?



It's a good thing i didn't fall for the full suckless suite. I only use st and dmenu.



It's sad because, despite suckless fags being massive pretentious faggots, dwm is a legitimately good piece of software, in terms of its core functionality.

But deliberately *removing* existing, already implemented features from future releases just because they are "a mess" is just overcomplicating things for no gain.

It's already tiny, much smaller than even st. There is really no point in dropping a widely used font standard.



Just maintain your own version and merge their improvements into your fork.



<lel just fork it if you don't like it

You sound exactly like the trannies who wrote the Linux CoC.

If they stop displaying non-ancient fonts, I'm just gonna kiss st bye bye and use a working terminal emulator instead.




The more niggerlicious terminals are so bloated they have input lag and so much overhead they can actually make a visible difference in how fast terminal programs run.


It's a name that describes the software perfectly, isn't it? Good enough.



urshitvt segfaults when I try to run it on my gentoo install.



Are you talking about daemon mode? For some reason, it needs Perl support compiled in to work correctly. I noticed this issue on multiple Linux distributions, including Gentoo. If not, when does it happen?



Not talking about daemon mode, but it does complain about perl now that you mention it.

Says it didn't find the extension "clipboard" even if I edit out the lines referencing the extension and reload the .Xresources



>complaining about maintaining changes to a minuscule source file

You might as well just kill yourself then, luser. Hope they drop your shitty fonts.



You use dwm/st and don't know that you use patches if you want additional features?



Niggers don't care about principles, as usual.

I honestly don't want to support unfinished software when working alternatives exists.

Sorry that triggers you so much.


I'm trying to migrate from st to xterm (image rendering is broken on st, at least for me) but I have 2 issues.

simpleterm displays bold characters with the brighter 8-15 colors, xterm also does, but it doesn't every time.

when I open vim with from simpleterm the theme uses the darker 0-7 colors, but when I open vim from xterm the theme uses the brighter 8-15 colors.

These 2 issues manifest with other programs, for instance neofetch from simpleterm uses the brighter colors for the distro logo ASCII art, and from xterm it uses the darker colors.

What the fuck is going on? I'm sure it's some xterm attribute I have missing, but I can't find it. I want to replicate the behavior I had with st on xterm.



Go use your gnome terminal then, luser. And stop complaining, nobody gives a shit about your complaints.


Doubt this kid can even apply a patch.



>download diff file

<run patch


Wow, so hard.

>And stop complaining, nobody gives a shit about your complaints.

You've been replying to him until now, I guess you kinda do give a shit.


st fucks up images for me as well. They blame it on w3m, but there has to be something else going on, as it works fine in every other terminal emulator I've used.



I managed to fix the issue. The vim part is because vim somehow correctly detects the background is dark and uses the lighter color range when using xterm, whereas when using st it doesn't, and defaults to dark, which means the text itself is light. Vim simply happened to behave like I wanted previously. I wanted a dark background with a dark theme, because it's better on the eyes.

The boldness thing can be replicated under xterm with some trickery that I eventually figured out.

If you're struggling with theming, I recommend you use my theme. The st header is nothing complicated, I just wrote in colors and a font. The .Xresources is xterm made to behave and look like st does under my configuration, which again is the defaults + colors/font. The only issue is that the text is slightly bigger on xterm because both terminals handle font sizes differently, st picks font size by pixels, xterm doesn't.

You'll need this font https://github.com/nathco/Office-Code-Pro

.Xresources is at: https://paste.pound-python.org/raw/jXcDzxPrDRIP9O6nQPol/

st 0.8.1 header at: https://paste.pound-python.org/raw/Zzhh4ggV059A87fo2qRj/

The theme is pretty simple, it's almost exactly the default set of colors every terminal uses, with a 100% black background, and light grey (#ababab) text. I just wanted something that doesn't burn my eyes.


When you get down to it, the terminal situation is terrible, isn't it?

They all fail at something. xterm can't do unicode properly because it doesn't use fontconfig and can't fallback on fonts. Unless your font supports every character even if just the ones you're likely to run into (not even noto does) it's going to not display something.

st breaks with images, and also some unicode glyphs.

When I mention "some" unicode glyphs I exclude the universally broken ones like arabic, I'm talking about chink characters that fail to render and emojis which like it or not retards are going to insert into software or talk with over irc rooms.

rxvt is in theory xterm but fixed, however in practice it's xterm but even more broken, plus perlshit bloat.

And then once you get into the DEshit terminals they're all pajeetshit so bloated they manage to take a few hundred megabytes of RAM and require a gigahertz CPU.



Yeah... problem is, people who want to "do things properly" often refuse to include useful features (plus most people use DE terminals anyway). I actually used to use some light terminal for most open terminal-do thing-close terminal uses and konsole for writing code, because it has some features that are quite useful (ligatures for fira code, it handles cursors properly, url highlighting...). Though now I usually have enough resources to not have to worry about them and since I use KDE, I might as well use konsole for everything.



Xterm is the root of the problem. It's buggy garbage, doesn't follow standards and retards writing code to control the terminal targeted its bugs instead of fixing the xterm situation.The result is nobody really understands what the fuck a terminal even is anymore. Some programs hard code xterm codes and other shit, others use terminfo and the whole thing is a literally unfixable mess. The only way to fix it is to trash literally everything and start from scratch.



>And then once you get into the DEshit terminals they're all pajeetshit so bloated they manage to take a few hundred megabytes of RAM and require a gigahertz CPU.

Kitty literally causes a power draw of 20 W on my system due to its GPU acceleration.



It's all the fault of UNIX.

I'm waiting for the multics-fag to appear

No but seriously, it's all broken. Is there even anything that works without you having to fight your machine half of the time?




Yeah I've read that article.

>In the UNIX world, the approach was to let the operating system kernel handle all the low-level details, such as word length, baud rate, flow control, parity, control codes for rudimentary line editing and so on.

>Fancy cursor movements, colour output and other advanced features made possible in the late 1970s by solid state video video terminals such as the VT-100, were left to the applications.

Yep. Even the motherfucking kernel hackers aren't up to the task of maintaining the tty subsystem in the kernel. I've read emails where they literally walk out on Linus after becoming too buttfrustrated by this tty shit.

But even that is less shitty than the user space terminal emulators situation. Because they're terminal emulators but do a shitty job at emulating anything. And applications start to rely on the shittiness. And other new emulators start emulating the SHIT instead of fixing it!



Because teletype machines are expensive and rare and cost money to operate?

Because they are compatible with software going back decades?

Are you retarded?



Just use screen or tmux, then you have unlimited scrollback.



I think most terminals update as fast as they run, and aren't fixed at a certain refresh rate.


>terminal emulators

>why learn the actual thing when you can learn many different languages that serve no purpose other than try to translate themselves into the first one


Where can I get a vt100?


I'm using xterm because of sixels support. That, and relatively fast opening speed on my slow machine. Konsole is much slower to open.



You would like to attach a literal vt100 to an UART and operate your system via /dev/ttyS0?



Fuck them - using st anyway.


>Reporting bugs" section in its entry in the Gentoo Wiki: https://wiki.gentoo.org/wiki/Rxvt-unicode is gold.



This one never does what it should. I have to honour tge idea behind your post though


By the way, how do I get powerline fonts to work in any of them (preferrably st though) on gentoo? I wanna try out the spacemacs config files but it looks like shit when all the glyphs are missing. It's literally the only thing that doesn't work yet.



>Download and install a patched font (from https://github.com/powerline/fonts)

>in st/config.h change the line char font[] = .. to "Your Font for Powerline:pixelsize=12:antialias=true:autohint=true"

>sudo make install

this relies on fontconfig, naturally


File: f660ef5f58afa4d⋯.png (1.56 KB, 932x468, 233:117, benis.png)


Moonrunes look like shit, but I see them literally two times per year max.




It works fine in everything but st? really? That's kinda strange. On my machine it seems that st fucks w3m img up the 2nd least. It's only perfect in framebuffer mode. On Arch. On Gentoo, w3m doesn't seem to support fb mode.

[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[ / / / / / / / / / / / / / ] [ dir / animu / hypno / leftyb / mde / mewch / nofap / pinoy / tingles ]