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

Waveterm

waveterm.dev

Post reply on HN
Print view View original

121–130 of 132 posts

Re: Waveterm

#121

Post by wiseowise »

IshKebab wrote: post #65
wiseowise wrote: post #34

Earlier quoted context omitted.

> Vim sucks. Why?

Two main reasons: 1. It has a ridiculous learning curve to get to the same editing proficiency as just having multiple cursors. All Vim users imagine themselves to be editing text at the speed of light while users of "lesser" editors struggle with scalar editing. I have seen zero evidence of that. Anyone of my colleagues that use Vim struggle to do basic tasks because remembering the gazillions of mnemonics is too on…

> It has a ridiculous learning curve to get to the same editing proficiency as just having multiple cursors.

It takes completing vimtutor to be faster than your average editing experience. What does it even have to do with multiple cursors?

> All Vim users imagine themselves to be editing text at the speed of light while users of "lesser" editors struggle with scalar editing. I have seen zero evidence of that.

I see it every day at work. Those who use vim are much faster on average.

> Meanwhile I can do anything I want very quickly in VSCode, and with immediate feedback!

Read and edit 100k lines file with syntax highlighting. I’d like to see that.

> It infests Unix by being the default editor in many situations (Git commit editing is probably the worst offender). Fine if you want to use your weird editor, but it should 100% not be the default editor EVER. There's a reason exiting Vim is a meme.

Right, because internet memes are a serious indicator of anything.

Re: Waveterm

#122

Post by wiseowise »

IshKebab wrote: post #100
jzb wrote: post #81

Earlier quoted context omitted.

Vim isn’t for you, and that’s fine. Statements like “all Vim users…” aren’t really a great contribution to the discussion. I’ve used Vim for 20+ years. I like it, you don’t have to. I don’t try to shove it down anyone’s throat - nor do I try to tell you why your favorite tool sucks. Because it probably doesn’t suck - for you. Tell me what you like or what doesn’t work for you and leave the middle school attitude wher…

> Vim isn’t for you, and that’s fine. See point 2. Vim isn't for 99% of people but it's somehow the default editor? Most people do not like Vim. That's why this project advertises not having to use Vim, because to 99% of people Vim is something that they don't want or like and can't even quit.

Most people who use vim absolutely love it, otherwise they wouldn’t use it on day to day basis. Those who don’t usually don’t care.

Re: Waveterm

#123

Post by sgt »

hnlmorg wrote: post #104
sgt wrote: post #101

Earlier quoted context omitted.

I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. And note the other threads here with people noting that even the VS Code terminal can get very slow.

> I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. SOME are concerned with millisecond latency, I agree. My point wasn't that there aren't users who care. It's that IF you care, then you shouldn't be using a multimedia terminal emulator. Putting rich content into the terminal will always add overhead. It doesn't matter if your t…

I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "imperceptive", it's in fact highly noticable. I guess I'll need to find a way to bring that hack back to life in order to show this to HN.

Re: Waveterm

#124

Post by frognumber »

sawka wrote: post #112
frognumber wrote: post #47

This looks nice, but I am very, very, very wary of adopting a tool like this without understanding the business model. There are two possible ways I've seen this go: 1) Build out a userbase. Once it's sufficient, monetize by screwing the userbase over in some way. 2) Take a bunch of VC money to build something awesome and open-source. Implode when there is no business model. I'm glad this is open-source -- that's pre…

founder/creator here. unfortunately this got posted without us being able to provide the proper HN background information, but i'll try to respond here. we are committed to open-source. we are committed to providing a free terminal (both free as in speech and free as in beer) to individual users. it doesn't cost us anything to have you run Wave locally, so we don't need to charge. plus if we did charge, open-source l…

Thank you.

Most HN posts are early-stage, where things are unfinished and mistakes happen, and are posted by the founder / creator for feedback (in part to catch those; we all have a blind spot with our own products!), so I wouldn't worry about it. At least with my community, such posts don't impact your reputation at all. General mantra is to share early precisely to catch those things, and it's important before adopting a tool, but unless things are secretive, it's best to share version 0.1 for feedback rather than to wait for something finished and polished.

My advice is to take what you wrote above, write it in enforceable legal language, and post it on your web site. It will go a long ways to driving adoption.

Once you add team and enterprise features, post similarly strong language about privacy and security. If I am managing regulated data in my day job (which I am), there had better be darned tight guarantees that FERPA/HIPPA/attorney-client/classified/etc. data doesn't end up sold to the highest bidder when your business goes under, gets bought by IBM, repackaged and sold to Oath, and finally resold to the Russian mafia.

Footnote: I would likely pay for the right enterprise features, especially around collaboration. On the other hand, with progress in LLMs, AI features can very much run locally on a $350 Arc 770 16GB GPU. The newer 7B models are very competitive with ChatGPT!

Re: Waveterm

#125

Post by hnlmorg »

sgt wrote: post #123
hnlmorg wrote: post #104

Earlier quoted context omitted.

> I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. SOME are concerned with millisecond latency, I agree. My point wasn't that there aren't users who care. It's that IF you care, then you shouldn't be using a multimedia terminal emulator. Putting rich content into the terminal will always add overhead. It doesn't matter if your t…

I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "imperceptive", it's in fact highly noticable. I guess I'll need to find a way to bring that hack back to life in order to show this to HN.

what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.

Re: Waveterm

#126

Post by eternityforest »

Levitating wrote: post #68
eternityforest wrote: post #15

It looks really nice! Ubuntu has made me slightly spoiled and less willing to try anything that's not packaged in the core repos, but maybe I'll make an exception. VS Code's integrated terminal is pretty great though.

Back when I used a debian based distribution I made use of https://bedrocklinux.org/ to make use of the AUR. It's not for everyone though.

Wow, that is super clever and really cool!

I can't imagine there not being some sort of Arch/Gentoo/LFS style Random Tech Trouble with that much custom craziness, but it does look kind of fun

Re: Waveterm

#127

Post by sgt »

hnlmorg wrote: post #125
sgt wrote: post #123

Earlier quoted context omitted.

I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "imperceptive", it's in fact highly noticable. I guess I'll need to find a way to bring that hack back to life in order to show this to HN.

what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.

The scientific research you refer to is basically looking at the equialent of a single keypress, or a specific delay to a frame or similar. Once you have a whole burst of sequential keypresses with an interactive interface, it becomes very evident. I'll see what I can do in terms of the experiment.

Re: Waveterm

#128

Post by wredue »

sawka wrote: post #110
wredue wrote: post #90

Earlier quoted context omitted.

This is not the terminal for me, but it looks like a pretty typical “as is, no warranty, no liability, telemetry is collected” TOS. Even if I was on the market for a slow, space wasting terminal, it appears venture backed, so enshitification is guaranteed making this terminal unusable from the onset.

I understand your concerns, but in this case venture backed means we have the resources to put full-time resources on it and push it forward quickly (as opposed to just being an interesting side project). We need an open source modern terminal alternative, otherwise this market will be taken over by closed source alternatives.

There’s lots of not venture backed open source terminals right now and even more being worked on.

Nobody who’s been paying any attention to the strong correlation of venture to enshittification is going to give this a second look.

Re: Waveterm

#129

Post by wredue »

wredue wrote: post #128
sawka wrote: post #110

Earlier quoted context omitted.

I understand your concerns, but in this case venture backed means we have the resources to put full-time resources on it and push it forward quickly (as opposed to just being an interesting side project). We need an open source modern terminal alternative, otherwise this market will be taken over by closed source alternatives.

There’s lots of not venture backed open source terminals right now and even more being worked on. Nobody who’s been paying any attention to the strong correlation of venture to enshittification is going to give this a second look.

Difficult to find due to the keywords involved. In point form:

-rcan used to generally lean slightly left, and banned terrible sources, bigotry as well as outright fake news

-metacanada didn’t like that white nationalism wasn’t allowed, and that far right “sources” weren’t allowed

-metacanadians get a couple people on the mod team who pretended for years to being more centrist/slightly left

-metacanadians began whining for MONTHS that the right wing had no representation on the mod team (except the couple that were there pretending to be reasonable)

-/r/Canada sleuths demonstrate that multiple mods on the team were in fact alts of metacanadians already, and that further implementing metacanadians mods would lead to a takeover

-/r/Canada mods disagreed, and installed a couple more /r/metacanada mods

-/r/metacanada now has the majority moderator total and begins a full takeover by actively harming the moderation and “showing the moderation is ineffective” which can lead to Reddit admins “stealing” a sub from you (and in this case did)

-/r/Canada is now essentially just an alt-right propaganda outlet that actively allows bigotry, and, in true conservative fashion, instantly bans criticism of the sub and mods.

Re: Waveterm

#130

Post by noergl »

sgt wrote: post #127
hnlmorg wrote: post #125

Earlier quoted context omitted.

what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.

The scientific research you refer to is basically looking at the equialent of a single keypress, or a specific delay to a frame or similar. Once you have a whole burst of sequential keypresses with an interactive interface, it becomes very evident. I'll see what I can do in terms of the experiment.

Keyboarders are prolly the ppl with fastest trained finger action on earth, be it on a computer keyboard or a music keyboard. In digital music production there is a magic threshold of 15-20ms latency for input signals - if a signal takes longer to process through your DSPs/computers lineup, any good musician will start to perceive the latency (btw thats more like an on/off phenomenon). Below that range we cannot detect any latency chance anymore, as our neural system is not made for higher time resolution (also the reason why 60 FPS gives us the illusion of a movie).

Typing latency on modern computers is really high compared to electronic or semi-digital typewriters of the 80s - those old machines had very little circuitry between the keypress and some output action, they were like hard-wired realtime machines to some degree. On today's machines there are tons of buffers, clocks, context switches etc. to pass, with no realtime promises anymore (at least not on typical consumer OS). We really have a "long line" in our machines today.

Electron adds another buffer stack to this madness - the browser engine needs to get the PTY chunks somehow, which is often done with websockets as IPC. Which means put chunks into a http frame, send through network stack to the electron browser engine, decode there - and finally the terminal sees the data as input. A desktop TE does not have to go through that, it can simply write the PTY chunk to its data structures in the same process. Thats the real overhead happening for data IO intensive electron apps regarding input latency.

Post reply on HN