New Dropbox uses half a gig of RAM and "sucks"

I’m surprised not to see Koofr mentioned here. I don’t have time to go into the details right now, but we’ve been a happy paid user for months now. Also, because it can basically merge Dropbox+Gdrive+OneDrive, the amount of free storage you can accumulate into one central cloud is quite noteable.

Except iOS. So, when I’m traveling and have only my phone to pull up copies of documents, it’s worthless. Darn.

1 Like

Is this like like the twenty-first-century version of rewriting everything in Java?

4 Likes

^^^^^^^ All of this.

Plus, Dropbox recently limited our free accounts to only 3 synced devices. I personally have 3 mobile devices and 2 laptops, so that sucks. Maybe the most surprising thing, though, is that Dropbox still had devices listed from many years ago. I think I had 17 devices linked, some of which are computers that died many years ago.

Yes, but worse.

More infuriating is when companies like GitHub replace actual native apps with Electron garbage and then try to destroy what words mean by calling it “the new native”.

5 Likes

Yeah, but that can’t waste half a gig of memory loading multiple copies of a userland driver for a Xbox 360 controller now can it?

:slight_smile:

2 Likes

The other electron apps I have on my computer are … Spotify ( Edit: Not quite - see below ) (200 megs) and Atom (260 megs).

I used to use Atom, but quit because it became very slow. Now I use Visual studio code.

Maybe I should expand my horizons?

The new Emacs. Eight megabytes and constantly swapping.

3 Likes

Same here. Atom was… unbearable. VS Code does use Electron but seems to work reasonably fast, at least on my relatively high-end hardware. I’ve considered doing stuff using vim and tmux like all the cool kids but vim’s weird clipboard system totally defeated me. I do use emacs and tmux, though, and for the kind of coding where autocomplete or IDE functionality isn’t an issue it works fairly well.

The modern system I like best is Xi but the frontends supporting it are rare and not very mature and I don’t have the surplus time to write my own. I do adore the idea of a modern editor you can use in the terminal and on the desktop, though.

2 Likes

I dunno exactly what your use-case is, but for actual native code editing apps on macOS, there’s the free CotEditor on the App Store (which is more for quick single-file edits), and the eternal BBEdit (which is more like VSCode from my recollection). There’s also Panic’s Coda, which is eventually getting a major overhaul and a new name once it’s finished, for stuff that’s more web-based projects.

1 Like

python, java, javascript-- the usual. Graphical diff is a big plus.

1 Like

When I read an Election vs NW.js comparison, and it talked about not needing to compile Chromium as much, I felt a twinge of dread. Looks like that twinge was right.

I assume that they have a wrapper app that runs a compiled and linked copy of Chromium, which runs their Javascript. Probably not linked in any nice way either, so that every Electron app has its own slightly different copy of Chromium on the disk, in your ram, killing your cores.

Oh dear.

3 Likes

I often wonder what a modern computer would feel like to use if you outfitted it with a suite of the sort of hand-tuned optimized apps like you used to get. I have tried to use a modernish computer using only the Linux command line and everything I did was blisteringly fast, but while you can do a lot from a command line, you can’t really do any web browsing so it wasn’t really a fair test.

That said, all the use of tmux did get me addicted to tiling window managers, so there is that. :slight_smile:

3 Likes

I use Spideroak, it’s pretty simple. I just checked and it’s using 130MB, which is decent considering how large a chunk of my HD is my “hive”

1 Like

I tell you, it all started with that O/S masquerading as an editor: emacs…

:crazy_face: … let the greybeards draw their staffs and commence fighting … :face_with_hand_over_mouth:

2 Likes

The future was supposed to be the browser as the OS, but instead it’s a different browser for every app like back in the day when GUI apps had a copy of GEM or Windows embedded.

I suppose there’s some reason that they don’t use THE browser as a smart terminal talking to a node.js server, other than making it look like a native app.

Somehow I doubt their “multi-platform” includes Raspberry Pis, so I’ll stick with Lazarus/Free Pascal with native code where a gig of ram is plenty.

1 Like

HOW ELSE CAN WE CONVINCE PEOPLE THEY NEED A NEW COMPUTER EVERY TWO YEARS

1 Like

maybe just os support? like how do you do task bar icons, tiles, or start menu shortcuts for a webapp? how do you add/remove programs?

even google docs and drive - which are probably some of the most well funded, most used web apps - don’t integrate all that well into macos and windows. and while they sort of have an offline mode, it requires some extra steps.

that said, the number of times ive opened spotlight or the start menu and tried to type “netflix” instead of first opening a browser… it’s basically uncountable at this point.

2 Likes

I should have said a local node.js server, which does have access to the OS. (It doesn’t need to be node.js. In theory, anything that can provide a local HTTP server for the browser. In practice, something with a framework, libraries and tools.)

  • Start menu shouldn’t be a problem. Start the server app, which opens the html file, which opens it in the browser, which connects back to the server.
  • Task bar could be tricky. The server app would have to display the browser on the correct tab. Some research to see if this is hard or a previously solved problem.

I sometimes wonder how much bloat is the result of security concerns. I know, I know. bloated code is much harder to audit.

But Chrome’s memory footprint derives at least in part from site isolation:

https://chromeunboxed.com/news/chrome-site-isolation-default-spectre-meltdown-ram-usage

Hypethreading is a securiity hazard (that can be huge for i7 and Xeon users.) Ironically, hyperthreading may be best deployed in a server environment, where cache misses, I/O generated wait states, etc cause the very noops that a SMT processor is good at mitigating. But a server environment is more likely to have bad actors than a well secured desktop environment…

Branch Prediction is a great way to stave off Moores law. But it’s a security hazard.

Hopefully , I’ve not revealed the depths of my ignorance, here.

1 Like