I would mostly rather them store things locally and explicitly ask me when to put my data in the cloud.
Provided that an application that performs the task you want exists for your phone's operating system. Apple iOS users have to contend with this fairly often, as Apple bans entire categories of native application from its App Store. And if an app is banned on the App Store, you need to buy a $799 Mac to run Xcode in order to load it onto your iPhone or iPad.
I have no idea what kind of miserable phone or plan you used that hijacks IP traffic in the way you describe
I too am on T-Mobile. But I'm on the $3 per month pay-as-you-go plan, which includes 0 MB/mo of cellular data, because I'm already paying Xfinity by Comcast for 1000 GB/mo of service at home and at its Wi-Fi hotspots around the city. The captive portal mechanism I described applies to all IP traffic over T-Mobile's 4G network.
Remember that Skype supported chat, voice, and offline messaging even in the mid-2000s.
Correct. It no longer does, as Microsoft switched off the protocol that the older software used. Part of the reason that the old software became impractical is that so many of its functions relied on peer-to-peer connections between participants in a conversation rather than a server. Peer-to-peer fails in two cases: A. when both sides are behind NAT that they cannot control, which will only become more common with the widespread adoption of carrier-grade NAT by ISPs; and B. when one or more of the receivers are offline. In addition, peer-to-peer connection exposes a participant's IP address, which makes a a participant's network connection more vulnerable to traffic-flooding DoS attacks. I'd be interested to see what the free software community creates to replace it. And back then, people didn't expect to use Skype through native mobile applications. Supporting three desktop platforms (Windows, macOS, X11/Linux) with native applications may be practical, but add iOS and Android and you may end up having to contract the desktop effort to one platform, namely Electron.
There's little these apps do that vim and emacs and IRC haven't done for decades for a tiny percentage of these requirements.
Vim and Emacs I'll grant. But IRC out of the box doesn't do chat history, file attachments, link preview, voice chat, or channel groups (Slack "workspaces" or Discord "servers").
To what extent does IRC out of the box support any of these?
1. Storage and forwarding of chat history, including messages sent to the channel while your device was offline. If the answer is a bouncer, which IRC server comes with a bouncer, and which IRC clients come with UI to integrate with said bouncer? 2. Storage and forwarding of text, image, and other file attachments. If the answer is DCC, then DCC fails behind carrier-grade network address translation (CGNAT), in which an ISP won't let an end user forward a port to his machine. It also fails when the sender and receivers aren't online at the same time. 3. Server-side link preview bot, so that several dozen clients aren't all hitting the site (and exposing their IP addresses) to fetch a client-side link preview. 4. Voice chat. 5. Sharing membership and permissions for all of the above across a set of related channels.
I've never seen an app that I think should pretend to be online when it isn't.
One example is navigation applications. You might want to have, say, Google Maps download a bunch of maps of your home town or a particular city that you are visiting. This way you don't use any of your monthly cellular data transfer allowance on mapping, or in my case, so that you don't have to buy any cellular data transfer allowance at all, instead relying on your wired home broadband connection. Other examples include note taking, word processing (Google Docs), web-based email client, forums, and the like, so that you can download something, compose changes or replies, and schedule them to be sent next time you connect.
And my phone's wireless hotspot does not cost extra to use.
To what country are you referring? Google (the developer of Chromium), Microsoft (parent company of the developer of Electron), and Slashdot (host of the forum on which we are discussing this) are all headquartered in the United States, where use of your phone's wireless hotspot often costs more than a basic cellular plan. (Or at least it did last time I looked, and on prepaid accounts as opposed to multline postpaid accounts.) If you enable the hotspot on your phone without first paying for an upgrade to a plan including hotspot use, then all DNS connections will be intercepted, all cleartext HTTP connections will redirect to a captive portal to log in and authorize payment for a plan upgrade, and all connections other than those will fail. It gets even more expensive when you're roaming internationally.
Without downloading an entire lightweight operating system to run in a virtual machine, and without paying three teams (or doing the work of three teams) to produce three applications, how would you prefer to make your application run on three different operating systems?
Distributing games as PC booters solved that by disallowing concurrent applications in the first place. Nowadays, video game publishers would prefer to disallow concurrent applications for two reasons: no third-party applications taking CPU, GPU, and RAM resources from the game engine, and no third-party utilities for running illegal copies or cheating in online play. Just look at any console-only game, for instance.
As the open runtime of the web becomes better and better, it will take over everything else.
It will be interesting to see what's left to parse the JS
Who is it that thinks this?
I think the other AC was trying to be cute. In context, I understood zmooc's comment as meaning "the only native app left will be the web browser," while AC wanted to push it further: "once the web browser goes not native, what will interpret it?"
PC booter software includes an operating system on the same floppy as the program. Many early IBM PC applications and most Apple II applications shipped as a booter, in part because it made copy authentication more robust. The same is true of games for PlayStation, PlayStation 2, the original Xbox, and all Nintendo game consoles prior to Wii U, which include any needed "library" or "operating system" code statically linked into the application.
Native apps used to have a performance edge, but that pretty much only remains for hard realtime stuff
Or for physically smaller, battery-powered devices where 8 GB of RAM is too physically large, too power-hungry, or too expensive, particularly tablet and compact laptop computers. If your device has 2 GB of RAM, then spending 365 MB per app on something like Skype or Discord (both built with Electron) will cause your device to lose performance to swap pressure fairly quickly, especially if it's running on the same device as a web browser whose user is using multiple tabs for page parking. Even 4 GB will cause more things to end up evicted from disk cache.
Discord (desktop version), Slack (desktop version), Skype (desktop version), and Visual Studio Code are all made with Electron. But the differences between Discord (desktop version) and Discordapp.com are quite minor: the option to let others know what game you are playing at the moment, system-wide push-to-talk in voice channels, and video chat capability.
The two alleged problems that Electron solves are 1. ability to hire from the web application programmer labor pool, and 2. less work needed to ship an application across four desktop/laptop platforms (Windows, macOS, X11/Linux, and Chrome OS).
Chromium is Google Chrome with the few proprietary components (mostly Adobe Flash Player and video DRM) stripped out. Node.js is Chromium's JavaScript engine repurposed as a server-side language. Electron, an application framework that Microsoft acquired when it bought GitHub, is a way to build a copy of Chromium hardcoded to one website, possibly bundled with Node.js. This allows a developer to ship a web application that can be installed as a desktop application.
Electron shares many disadvantages with the web platform. But one significant advantage of Electron is that you're less likely to get "Sorry! This application is not yet available for your platform. Subscribe to our mailing list to be the first to know when the crowdfunding campaign to port this application to your platform begins."
No runtime and no dependencies for the target executable
This is because everything is statically linked. For example, last time I built the release build of the driver to load games onto a USB RAM cartridge for the Game Boy, it pulled in enough crates to total 6,787,656 bytes of executable code. How would this integrate with the UNIX philosophy's rule of composition, where a task consists of a half dozen or more different processes? Would all the processes have to be built into one executable that uses the executable's name to determine which sub-program to run? Or would it be better to repeat the libraries in a half dozen or more executables, storing all them on disk or NAND flash and retransmitting them over a possibly metered Internet connection whenever program or its libraries need to be updated?
In fact, the throughput difference is so huge that switching from SATA to PCIe drops a compile time on one of my projects by 70%, So what did I end up doing? I ordered a Lenovo laptop that supports NVMe PCIe [...] I will never buy another Apple computer again.
Not even when asked to compile and test a macOS or iOS port of the application that you are compiling?
Slashdot Mirror
I would mostly rather them store things locally and explicitly ask me when to put my data in the cloud.
Provided that an application that performs the task you want exists for your phone's operating system. Apple iOS users have to contend with this fairly often, as Apple bans entire categories of native application from its App Store. And if an app is banned on the App Store, you need to buy a $799 Mac to run Xcode in order to load it onto your iPhone or iPad.
I have no idea what kind of miserable phone or plan you used that hijacks IP traffic in the way you describe
I too am on T-Mobile. But I'm on the $3 per month pay-as-you-go plan, which includes 0 MB/mo of cellular data, because I'm already paying Xfinity by Comcast for 1000 GB/mo of service at home and at its Wi-Fi hotspots around the city. The captive portal mechanism I described applies to all IP traffic over T-Mobile's 4G network.
How could they even know I turn the phone into a hotspot?
The two I can think of are 1. accessing non-mobile versions of websites, and 2. accessing the update servers for desktop operating systems.
[Carriers in Europe] neither have knowledge of, nor influence on what software I run on the handset.
Carriers in the United States tend to sell co-branded handsets that can use only SIMs issued by that carrier.
Uh...what part of "-style chat interface" did you not get?
The fact that people like Drew DeVault and Benjamin Pollack have written blog posts promoting IRC over Slack (and Skype and Discord). On the other hand, Dave Cheney thinks all chat platforms are inferior to forums and mailing lists.
Remember that Skype supported chat, voice, and offline messaging even in the mid-2000s.
Correct. It no longer does, as Microsoft switched off the protocol that the older software used. Part of the reason that the old software became impractical is that so many of its functions relied on peer-to-peer connections between participants in a conversation rather than a server. Peer-to-peer fails in two cases: A. when both sides are behind NAT that they cannot control, which will only become more common with the widespread adoption of carrier-grade NAT by ISPs; and B. when one or more of the receivers are offline. In addition, peer-to-peer connection exposes a participant's IP address, which makes a a participant's network connection more vulnerable to traffic-flooding DoS attacks. I'd be interested to see what the free software community creates to replace it. And back then, people didn't expect to use Skype through native mobile applications. Supporting three desktop platforms (Windows, macOS, X11/Linux) with native applications may be practical, but add iOS and Android and you may end up having to contract the desktop effort to one platform, namely Electron.
There's little these apps do that vim and emacs and IRC haven't done for decades for a tiny percentage of these requirements.
Vim and Emacs I'll grant. But IRC out of the box doesn't do chat history, file attachments, link preview, voice chat, or channel groups (Slack "workspaces" or Discord "servers").
Slack, a simple IRC style chat interface
To what extent does IRC out of the box support any of these?
1. Storage and forwarding of chat history, including messages sent to the channel while your device was offline. If the answer is a bouncer, which IRC server comes with a bouncer, and which IRC clients come with UI to integrate with said bouncer?
2. Storage and forwarding of text, image, and other file attachments. If the answer is DCC, then DCC fails behind carrier-grade network address translation (CGNAT), in which an ISP won't let an end user forward a port to his machine. It also fails when the sender and receivers aren't online at the same time.
3. Server-side link preview bot, so that several dozen clients aren't all hitting the site (and exposing their IP addresses) to fetch a client-side link preview.
4. Voice chat.
5. Sharing membership and permissions for all of the above across a set of related channels.
ChromeOS, well Electron doesn't matter because you are forced to deliver it as a browser extension anyway.
Electron allows your Chrome OS browser extension to share code with your Electron-powered "native" applications for Windows, macOS, and X11/Linux.
I've never seen an app that I think should pretend to be online when it isn't.
One example is navigation applications. You might want to have, say, Google Maps download a bunch of maps of your home town or a particular city that you are visiting. This way you don't use any of your monthly cellular data transfer allowance on mapping, or in my case, so that you don't have to buy any cellular data transfer allowance at all, instead relying on your wired home broadband connection. Other examples include note taking, word processing (Google Docs), web-based email client, forums, and the like, so that you can download something, compose changes or replies, and schedule them to be sent next time you connect.
And my phone's wireless hotspot does not cost extra to use.
To what country are you referring? Google (the developer of Chromium), Microsoft (parent company of the developer of Electron), and Slashdot (host of the forum on which we are discussing this) are all headquartered in the United States, where use of your phone's wireless hotspot often costs more than a basic cellular plan. (Or at least it did last time I looked, and on prepaid accounts as opposed to multline postpaid accounts.) If you enable the hotspot on your phone without first paying for an upgrade to a plan including hotspot use, then all DNS connections will be intercepted, all cleartext HTTP connections will redirect to a captive portal to log in and authorize payment for a plan upgrade, and all connections other than those will fail. It gets even more expensive when you're roaming internationally.
Without downloading an entire lightweight operating system to run in a virtual machine, and without paying three teams (or doing the work of three teams) to produce three applications, how would you prefer to make your application run on three different operating systems?
Distributing games as PC booters solved that by disallowing concurrent applications in the first place. Nowadays, video game publishers would prefer to disallow concurrent applications for two reasons: no third-party applications taking CPU, GPU, and RAM resources from the game engine, and no third-party utilities for running illegal copies or cheating in online play. Just look at any console-only game, for instance.
As the open runtime of the web becomes better and better, it will take over everything else.
It will be interesting to see what's left to parse the JS
Who is it that thinks this?
I think the other AC was trying to be cute. In context, I understood zmooc's comment as meaning "the only native app left will be the web browser," while AC wanted to push it further: "once the web browser goes not native, what will interpret it?"
PC booter software includes an operating system on the same floppy as the program. Many early IBM PC applications and most Apple II applications shipped as a booter, in part because it made copy authentication more robust. The same is true of games for PlayStation, PlayStation 2, the original Xbox, and all Nintendo game consoles prior to Wii U, which include any needed "library" or "operating system" code statically linked into the application.
Who's different from whom? Which widespread applications had "OK to left of Cancel" prior to the 1984 introduction of Mac OS 1.0?
Why that fucking butterfly keyboard was ever approved
I thought IBM invented the TrackWrite butterfly keyboard for the ThinkPad as a way to fit a non-cramped keyboard on a subnotebook.
The OS vendors/distributors themselves aren't providing coherent, unified UI language
Well, there are GNOME Human Interface Guidelines. But why don't more GTK+ apps follow them?
Would "We're sorry! This application is not yet available for your platform" architecture be less bad than Electron?
You need PWA to access cached web resources or private data while your device is not connected to the Internet.
"Then just go online!" Cellular hotspot data transfer is not free.
Native apps used to have a performance edge, but that pretty much only remains for hard realtime stuff
Or for physically smaller, battery-powered devices where 8 GB of RAM is too physically large, too power-hungry, or too expensive, particularly tablet and compact laptop computers. If your device has 2 GB of RAM, then spending 365 MB per app on something like Skype or Discord (both built with Electron) will cause your device to lose performance to swap pressure fairly quickly, especially if it's running on the same device as a web browser whose user is using multiple tabs for page parking. Even 4 GB will cause more things to end up evicted from disk cache.
Discord (desktop version), Slack (desktop version), Skype (desktop version), and Visual Studio Code are all made with Electron. But the differences between Discord (desktop version) and Discordapp.com are quite minor: the option to let others know what game you are playing at the moment, system-wide push-to-talk in voice channels, and video chat capability.
The two alleged problems that Electron solves are 1. ability to hire from the web application programmer labor pool, and 2. less work needed to ship an application across four desktop/laptop platforms (Windows, macOS, X11/Linux, and Chrome OS).
Chromium is Google Chrome with the few proprietary components (mostly Adobe Flash Player and video DRM) stripped out.
Node.js is Chromium's JavaScript engine repurposed as a server-side language.
Electron, an application framework that Microsoft acquired when it bought GitHub, is a way to build a copy of Chromium hardcoded to one website, possibly bundled with Node.js. This allows a developer to ship a web application that can be installed as a desktop application.
Electron shares many disadvantages with the web platform. But one significant advantage of Electron is that you're less likely to get "Sorry! This application is not yet available for your platform. Subscribe to our mailing list to be the first to know when the crowdfunding campaign to port this application to your platform begins."
No runtime and no dependencies for the target executable
This is because everything is statically linked. For example, last time I built the release build of the driver to load games onto a USB RAM cartridge for the Game Boy, it pulled in enough crates to total 6,787,656 bytes of executable code. How would this integrate with the UNIX philosophy's rule of composition, where a task consists of a half dozen or more different processes? Would all the processes have to be built into one executable that uses the executable's name to determine which sub-program to run? Or would it be better to repeat the libraries in a half dozen or more executables, storing all them on disk or NAND flash and retransmitting them over a possibly metered Internet connection whenever program or its libraries need to be updated?
Linux, yes. Google Play Services, not so much. The latter is proprietary.
What add-ons are you missing, by the way?
Keybinder. It was canceled due to deficiencies in WebExtensions that remain unfixed a year later, particularly Bug 1325692.
In fact, the throughput difference is so huge that switching from SATA to PCIe drops a compile time on one of my projects by 70%, So what did I end up doing? I ordered a Lenovo laptop that supports NVMe PCIe [...] I will never buy another Apple computer again.
Not even when asked to compile and test a macOS or iOS port of the application that you are compiling?
(soldered)
Deal killer.