It's unfortunate that as startups get larger, the speed of improvement on their product often gets slower. It's strange to me that Dropbox has thousands of employees, people have wanted this for a _long_ time, and yet this hasn't been built. You'd think that with more engineering/PM/design talent the product would get better, and faster. Anyone have any insight into why happens? I've never worked at a early stage sta…
One thing I’ve seen: feature priority driven by what is expected to drive sales. This is a feature that I could see, justified or not, as not driving adoption.
It's unfortunate that as startups get larger, the speed of improvement on their product often gets slower. It's strange to me that Dropbox has thousands of employees, people have wanted this for a _long_ time, and yet this hasn't been built. You'd think that with more engineering/PM/design talent the product would get better, and faster. Anyone have any insight into why happens? I've never worked at a early stage sta…
Overhiring. Individual productivity goes down the more the company hires. At one point big software companies are only big because they can afford to be big. I wrote about it here https://medium.com/@franz.enzenhofer/overhiring-b966a6ff383d...
I read this somewhere on HN: if your company has $1 million in ARR with 3 people, you'll likely feel need to hire more people, even if the 3 people get the job done.
Now repeat this with $1 billion in ARR...you get the picture.
I've seen "Bullshit Jobs" recommended here on HN [1].
Why not just use github, gitlab or other VCS? Personally, I enjoy using Dropbox for music projects (which VCS are not well suited for), but for code... (I apologize if I sound as if I'm telling you what you should be doing; I am really just trying to understand the motivation behind such a decision - but I fully understand that even if something seems bizzare to me, it's just my personal humble uninformed opinion).
>Why not just use github, gitlab or other VCS? You can only revert changes to states that you have explicitly stored and uploaded. Dropbox does that automatically any time you save a file. That simplicity makes it more reliable. You will never lose anything you saved. And with rewind you can go back to any point in time. The advantage of git comes from its branch/merge features. But for a single developer on a small…
I moved my notes folder to git after having conflicted files for the upteemth time from Dropbox.
Two things that keep everything in sync:
1. Every two minutes my notesync.sh script runs, which basically does git add --all;git commit -am "New commit";git pull;git push.
2. Vim with AutoSave.vim which saves the document as I write.
Yes, there are a lot of commits, but I don't have to worry about losing anything.
FYI I tried this feature out a few months ago and found it to be useless for build folders. Extended attributes (xattr) get lost everytime you recreate a file/folder - think 'build', 'node_modules' etc. Additionally Dropbox broke selective sync which is even more infuriating. All this combined means my hard drive is running all the time.
The most requested feature, to allow a file or folder to be ignored by Dropbox sync without using selective sync is finally in beta. The community requested a .dropboxignore file but they chose another solution which I’m sure is reasonable for making the feature more user friendly to non-devs. This will be immensely helpful for node_modules or build target directories.
I can imagine a world where a arbitrary directory is filled with gitignore, dropboxignore, googledriveignore, backblazeignore, s3ignore, rsynciginore, dotignore, ipfsignore . . . Goddamn, stop the world I want to get off
What missing is .folderinfo/ to hold those things, akin to HFS resource fork or file attributes
> This will be immensely helpful for node_modules or build target directories. Why would anyone put a node project in Dropbox to begin with?
After an office break in and having my laptop stolen my company gave me dropbox to back up my home folder. Dropbox actually managed to completely hose every single node_modules folder by the end of the week. It got confused somehow then ended up just splitting all the files up with dates on them as if there was a conflict across hundreds of files. Stopped using it after that.
Your company didn't have backups until it had a break-in?
I think the problem here is poor tooling that contaminates your working directory. If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). Thus there are no artifacts to gitignore. OCI container builds ("docker images") are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm/container, copying a working directory into the container…
> If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). That is a terrible design, as it makes parallel builds error prone.
Bazel is the king of parallel builds though, at work we can spread out 100 actions wide across across a cluster of machines, and the only reason it's that small is we have no real need to go wider...
I think the problem here is poor tooling that contaminates your working directory. If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). Thus there are no artifacts to gitignore. OCI container builds ("docker images") are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm/container, copying a working directory into the container…
> If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). That is a terrible design, as it makes parallel builds error prone.
Output directories are unique by the user and source project workspace directory. Output artifacts don't clobber, even though they are all in ~/.cache.
You can use the mklink command to link files since windows 7 https://www.tenforums.com/tutorials/131182-create-soft-hard-...
All linking tricks are often defeated if the program in question writes to the file. Especially on windows, it's common practice to first write out a new file, if you didn't crash, remove the old file and rename the new file. This breaks the link. I'm not sure if this is also common for config files, but I would not be surprised.
Just link the parent folder into dropbox, I do it for savegames all the time.
Or switch to resilio sync, it’s great and selfhosted. Unlimited folders can be used.
I put everything in Dropbox including all of my projects. In my experience it works pretty well even if node_modules can't be ignored now. Putting every projects in Dropbox with .git is the most awesome feature of Dropbox. With Dropbox's History and Time Machine feature, you will be almost never able to delete/overwrite your work permanently, even by intention.
Why not just use github, gitlab or other VCS? Personally, I enjoy using Dropbox for music projects (which VCS are not well suited for), but for code... (I apologize if I sound as if I'm telling you what you should be doing; I am really just trying to understand the motivation behind such a decision - but I fully understand that even if something seems bizzare to me, it's just my personal humble uninformed opinion).
They're completely different tools with different benefits, and both can be used together. VCS remembers only what you commit and push, per-project. Dropbox remembers your entire workspace as a whole, automatically. It remembers every time you save any file (more detail than you usually need, but can be handy in an emergency). It also remembers which projects you have on the go, and how they're organised. It remembers all the unpushed stuff within each project, including uncommitted changes, stashed changes, experimental branches, gitignored notes and ideas, even the knowledge of which branch you are currently on. Your entire workspace. And by 'remembers', I mean it automatically syncs all that stuff to all your devices, so your workspace is always exactly as you left it, whichever device you're now using.