Hacker News Reader

Comment by robotron | Hacker News Reader

At first, I thought "what's the point?" Then I saw:

"It's not built on top of web browser technology: it responds quickly to input, sips gently from computer resources, and gets out of your way."

View on HN

I don't actually use any of these services so I had no need to, but just being curious, I downloaded the Windows client; and while it may be smaller than Electron apps and native, it's still quite large for a native app --- over 30MB, and also 64-bit only (why? Do you expect to need more than 4GB of RAM for this?)

To contrast, MSN Messenger 4.7, an app with similar capabilities (IM, voice, and video calling), is only ~2MB --- with several third-party reimplementations being <1MB. Makes you wonder how small you can make an app for today's messaging services if you really tried... they don't need to be that big even if they don't include an entire web browser.

Most of the stuff is taken from the fact that Ripcord is multiplatform. It uses Qt5, it takes lots of space, but works everywhere. Ripcord also bundles lots of libraries for lots of file formats (audio, video), bundles OpenSSL for cryptography support (although the library is from 2014, and probably should be updated), should theoretically support Wayland (at least it has some libs for supporting it), etc.

MSN Messenger probably uses WinAPI and being a Windows-only program it can get away with it.

Its not like 32 bit applications are more efficient than 64 bit applications.

There is place for 32 bit applications but not here! The job of a program is to do what it is supposed to do efficiently and get out of the way, and it better use all registers and instructions needed to do it.

Its not like 32 bit applications are more efficient than 64 bit applications.

Yeah it is. You need to move 7 bits through memory and through the CPU, is it more efficient to pad it with 25 blank bits and move 32 bits overall, or pad with 57 blank bits and move 64 bits overall?

Which is doing things "more efficiently" and "better using" the hardware?

If you use eax instead of rax, you can do both. Compilers are smart these days and will use the appropriate register size when necessary. If you need to move 7 bits, it'll likely use the al register.

I can't edit, but it seems my reasons for thinking 32-bit can be faster aren't entirely daft - but the gains of 64-bit x64 include it having simply more registers, having smaller faster floating point precision, being able to request more memory at once, and the hits to pointer size overheads or processor cache holding less real data are rare and mostly from buggy or odd conditions, and that for a lot of normal programs there'll be no difference either way:

https://stackoverflow.com/questions/2378399/are-64-bit-progr...

https://stackoverflow.com/questions/324015/supplying-64-bit-...

https://stackoverflow.com/questions/2334148/is-there-any-rea...

interesting.

thats not the question you have to ask though.

your cpus arent capable of 32 bit calculations anymore... so the questions is: is the software emulation of your OS for 32 bit more efficient than the programming language overprovisions.

The CPU is still perfectly capable of 32bit calculations. Even 8 bit calculations. What you can't do is use 32bit pointers (though, strictly, you can, but x86-32 isn't well supported, I wonder why?)

You are technically right, but only because I expressed myself very poorly.

The CPU is naturally still able to do 32 bit calculations.

What you can't do is run a 32 bit application without emulation after a 64 bit system has booted.

The libraries are obviously also required, but it still won't be able to start without the emulation adding 0 to the memory blocks.

Source? Not that I don't believe you, I just don't understand from your comment

It's not -entirely- true but it's not false, either as far as I'm aware.

Windows in specific uses WOW64 -- Windows 32 on Windows 64. It's an emulation layer that doesn't actually hamper performance but does do things a bit differently than a native OS -- such as running all 32bit programs in 'user mode' rathe than with elevated permissions.

You can get a brief synopsis here - https://www.techsupportalert.com/content/how-windows7-vista6...

I'm surprised at the criticism about 64-bit only. Are people still using 32-bit operating systems?

Honestly I would criticise if it was 32-bit.

When can I finally get rid of this stupid "Program Files (x86)" folder which annoys me every time I click into the wrong one looking for my program, when even new programs are released as 32-bit?

Yes.

A 32-bit binary will work just fine on a 64-bit OS, but not the other way around, and there's no reason such an app needs 64-bit, so why unnecessarily restrict compatibility?

I think you're in a minority. Are there any 32-bit CPUs being produced for the mass market these days? Making a 64-bit only software is not only about wanting more than 4gb of ram; it's about debugging support, tooling, installation size and installation packages, etc. It's easier to distribute 64-bit only software than both 32-bit and 64-bit, and you can't distribute 32-bit only software because:

1. macOS will deprecate 32-bit completely soon,

2. Linux needs 32-bit libs installed on the system, and many people don't have them,

3. Windows has really good backward compatibility and still supports 32-bit. But it's the only system.

So, distributing a 64-bit-only software actually makes sense.

This exactly.

When I install something, if it pulls in a ton of stuff, I'll reevaluate whether I actually need it. In fact, I was pretty excited when I finally got rid of my dependency on 32-bit stuff and could eliminate the 32-bit repo.

I like 64-bit because it keeps my system clean, but because it's "better". I definitely want a 64-bit OS so some things can use more than 4GB RAM, so why have two copies of everything? Just standardize on the thing nearly everyone uses: 64-bit.

Are there any 32-bit CPUs being produced for the mass market these days?

Can we stop assuming that people are always going to have the latest hardware? Even then, 32-bit SoCs running Linux are still pretty common in various embedded things and other low-power devices --- exactly the use-case for a small and native chat client.

You don't need the latest hardware to have a 64-bit CPU.

Slack client on an embedded platform? Are you ok?

Not exactly true for Linux - a modern Linux desktop usually has only the most basic (libc, ...?) 32 bit libraries installed. Though an AppImage (which Ripcord uses) might work because it's mostly self-contained anyway. On Linux, approximately nobody still uses 32 bit systems.

> it's still quite large for a native app

It's not native (as in native windowing toolkit), it's Qt based which is probably where most of that 30MB is going, MSN Messenger is/was built on win32. Still, in the age of electron apps that's a huge improvement, it's good to see real desktop developers still exist.

Reminds me of my IRC client.

I wish I could use my IRC client: https://news.ycombinator.com/item?id=16539857

You can. See my top-level comment on this post https://news.ycombinator.com/item?id=19618630

I mean I wish we just stopped there, IRC, done, call it a day, never ever think about many to many written communication ever again. It works, scales, supported on all platform, text based, small memory/cpu footprint. Just like we stopped developing hammers a while ago. CS is the only field where 1.0 is never good enough. We keep "innovating" adding features that nobody needs and complicating things until it becomes this unmanagable mess. </rant>

As a big fan of IRC, I would have to say that it doesn't "work" at all when compared to Slack or Discord. You have to be online to receive messages, making it pretty much useless for any serious communication needs. Yes, I am aware of, and run, an IRC bouncer, this is not a real solution for 99% of users.

It's also limited to straight text. People may say it's frivolous, but sending pictures and other media is expected now.

Don't forget NickServ. It's a pretty massive user bottleneck. More than half of the people in my (tech) company would probably take more than 20 minutes to figure that out.

I used to spend a fair bit of time in a non-tech IRC (we've moved to Discord since) and the amount of intelligent people who simply could not get the hang of NickServ was astounding.

I've always wondered why IRC clients didn't add seamless integration with NickServs of large networks. Maybe this was one of the reasons why services like Slack or Discord are successful; these services are taking your hand and are guiding you through everything, while IRC expects the user to read RFC and diagnostic server output in order to figure what's going on. I don't think it has to be this way.

IRC as a protocol probably can be used to build a service as friendly as Slack. I.e. it's not a problem to add URL autoexpansion, like in this WeeChat plugin: https://github.com/antekone/youtube-autoexpand . Of course it's not easily possible or practical to show pictures inside of the terminal window, but I think it's entirely possible to create a new modern Slack-competitive IRC client over a pure IRC network. What could be done on IRC can be seen in an old Microsoft app, Microsoft Comic Chat: https://en.wikipedia.org/wiki/Microsoft_Comic_Chat .

(disclaimer: i prefer IRC to Slack/Discord but I get why for many people IRC is a bad idea)

NickServ always felt like a terrible hack to me. It doesn't help that some major servers have incredibly stingy limits on NickServ too. I've had usernames age out after only a week, and the registration process is fairly cumbersome. Plus it involves sending a password in plaintext over the network, which never felt good.

IRC is not limited to plain text. Discord, Slack, and IRC all handle media the same way. Someone sends an URL and the client decides to how to handle displaying it. Textual shows me images and videos all the time from URLs sent.

That's not how I use the feature at all. The vast majority of images and files I send are created locally. I can then upload or paste then into the chat client, they get stored on the server and shown to the other users. With IRC, I would need to use a separate service like imgur to first upload the images. And or a file hosting service like Dropbox for the files.

A robust IRC client could include integrated image hosting. Or ask you to plug in your Dropbox account, and then upload there automatically when you drag and drop a file or image.

Have you seen irccloud?

I guess then technically IRC servers need a way to have images uploaded and re-serve them. When I share an image on slack I'm usually just uploading it directly to slack, rather than using imgur or another uploader.

I thought they stored the graphics on the server with Discord. I know there is that out-of-band file protocol that some IRC clients support, but it was always a terrible hack that hated firewalls.

That's incorrect - you can send binaries over IRC with DCC.

Unless things have changed since my IRC days, doesn't this a) require routed ports, so anything not a private controlled network is out, b) expose your IP address, which is a security risk, and c) is 1:1 only. It's also more of a side protocol than actually being part of IRC, right?

Whereas posting images directly into the chat window and having everyone see it is insanely useful.

It does not have full slack-like functionality. But it was never limited to just text. Some of the biggest communities on IRC revolve(d) around file sharing over DCC.

Anyway I think saying that it's "insanely" useful is a gross exaggeration. You know what is insanely useful though? Having open source clients and access to logs without paying $100 per year per user.

So, our small team is using google hangouts but that also supports image pasting (and is searchable, free).

Image pasting is for more than just memes. We can post screenshots of errors, or user data/visualisations, or sections of syntax-highlighted code. All of this is infinitely more agile than going through a bulky ticket system (which we also use once we’ve confirmed as bugs or decided how to use forwards). So no, it’s not an exaggeration at all.

IRC was fun in the 90s but seems to have stopped there? It was also never ~at all~ friendly for non-technical users, which is a complete non-starter nowadays.

The alternative to pasting images is making a ticket? I would have thought it would be uploading images to some image hosting site and then pasting a link.

Only receiving messages while online is a feature. Want to work async? Email.

Except some people can be having a conversation while I'm offline. When I get back on, I can catch up or have someone link me to an important part of it. It's handy.

I work with a bunch of people in oakland, where comcast flickers on and off like a light bulb during a wind storm in the 1920's. So the only way to have a quick chat is over email?

A feature to the small handful of people who still use IRC. Look around though. Everyone else expects basic features like being able to send someone a message even though that person went through a tunnel.

In some teams, IM+history is the email killer that happened by the mistake.

Many IRC servers provide a service that allows users to send messages to offline users, which are then relayed to the user when they come online.

Kind of a toothless "many" when this isn't even built into Freenode. I have to wonder if any IRC server I've ever connected to supported it and why I've never seen this feature.

Freenode does support it.

   -MemoServ(MemoServ@services.)- ***** MemoServ Help *****
   -MemoServ(MemoServ@services.)- MemoServ allows users to send memos to registered users.
   -MemoServ(MemoServ@services.)-  
   -MemoServ(MemoServ@services.)- For more information on a command, type:
   -MemoServ(MemoServ@services.)- /msg MemoServ help <command>
   -MemoServ(MemoServ@services.)-  
   -MemoServ(MemoServ@services.)- The following commands are available:
   -MemoServ(MemoServ@services.)- DEL             Alias for DELETE
   -MemoServ(MemoServ@services.)- DELETE          Deletes memos.
   -MemoServ(MemoServ@services.)- FORWARD         Forwards a memo.
   -MemoServ(MemoServ@services.)- HELP            Displays contextual help information.
   -MemoServ(MemoServ@services.)- IGNORE          Ignores memos.
   -MemoServ(MemoServ@services.)- LIST            Lists all of your memos.
   -MemoServ(MemoServ@services.)- READ            Reads a memo.
   -MemoServ(MemoServ@services.)- SEND            Sends a memo to a user.
   -MemoServ(MemoServ@services.)- SENDOPS         Sends a memo to all ops on a channel.
   -MemoServ(MemoServ@services.)- ***** End of Help *****

It's a common IRC bot feature. Typically there's a command like: .tell <user> <message>

For future reference to OP: the term you're looking for is "modern web technology" or "modern technology"

Emphasis on "modern" --- I distinctly remember using some web chat clients with IE6 in the early 2000s, and they didn't need hundreds of megabytes of RAM (average PCs had a total of between 64 and 256MB of RAM) and the whole (single-core at the time) CPU to do what today's web apps do.

For anyone who knows what I mean, it might be interesting to write such a "lightweight" web client for e.g. Slack, restricting yourself to whatever JS abilities were available in 2000 or so, yet imitate as much of the features and appearance of the web client today as possible. Chances are it will still work with "modern" browsers too, and use a tiny fraction of the resources of the current one. All the better if it gets noticed and DMCA'd.

JIT engines operate on a time-memory tradeoff.

Oh please. I'm not about to start referring to a specific toolkit as "modern technology” at the expense of everyone else, particularly a step backwards

That was meant as a sarcasm and I was pretty sure anybody who hates electron would get it. Sadly, no.

Who cares that it's not built in Electron? Slack is plenty fast, your average user does NOT notice the difference.

I notice how long it takes to start up the app, I notice how hard my CPU fan runs when Slack inexplicably decides to max out a whole core for a few minutes, I notice the data hit if I have to download a new version while on the road. It's definitely bloatware.

But I do notice and on my machine I prefer lightweight apps, so I can make the most of my existing resources instead of wasting them on a chat application.

My laptop battery sure does. Electron is legitimately wonderful, but apps built on it are often horrible CPU hogs.

If you're in more than one workspace it can take literally 5-10 seconds to transition between them while showing some BS motivational message.

Slack lags seconds behind when I type anything.

I actually ran into that today and restarting the app fixed it. That shows that there's a pretty serious limitation if such a high profile app has these sorts of problems.

They will.

Reply on news.ycombinator.com