Slashdot Mirror
What Dropbox Dropping Linux Support Says (techrepublic.com)
Jack Wallen, writing for TechRepublic: For a company to support Linux, they have to consider supporting: Multiple file systems, multiple distributions, multiple desktops, multiple init systems, multiple kernels. If you're an open source developer, focusing on a single distribution, that's not a problem. If you're a company that produces a product (and you stake your living on that product), those multiple points of entry do become a problem. Let's consider Adobe (and Photoshop). If Adobe wanted to port their industry-leading product to Linux, how do they do that? Do they spend the time developing support for ext4, btrfs, Ubuntu, Fedora, GNOME, Mate, KDE, systemd? You see how that might look from the eyes of any given company?
It becomes even more complicated when companies consider how accustomed to the idea of "free" (as in beer) Linux users are. Although I am very willing to pay for software on Linux, it's a rare occasion that I do (mostly because I haven't found a piece of must-have software that has an associated cost). Few companies will support the Linux desktop when the act of supporting means putting that much time and effort into a product that a large cross-section of users might wind up unwilling to pay the price of admission. That's not to say every Linux user is unwilling to shell out the cost for a piece of software. But many won't.
It becomes even more complicated when companies consider how accustomed to the idea of "free" (as in beer) Linux users are. Although I am very willing to pay for software on Linux, it's a rare occasion that I do (mostly because I haven't found a piece of must-have software that has an associated cost). Few companies will support the Linux desktop when the act of supporting means putting that much time and effort into a product that a large cross-section of users might wind up unwilling to pay the price of admission. That's not to say every Linux user is unwilling to shell out the cost for a piece of software. But many won't.
Except Dropbox wants access to your filesystem details for their backup stuff., not just the file descriptor and data.
"2 Types of Linux File Locking (Advisory, Mandatory Lock Examples)": https://www.thegeekstuff.com/2...
This might be of some interest to you.
l wrote software that creates and syncs and *bootable* copy of a Linux machine. To have the clone boot and run right, everything needed to be copied over exactly - extended attributes included.
It CAN be hard if you try to do it using the approach you are thinking of, but there is a much easier way. JavaScript programmers will recognize these two different approaches.
> does the file system support symlinks, does it support locking? Can we reliably see if the file changed while we tried to sync it?
stat() will tell you if the file is a symlink and when it last changed. If this file is a symlink, then it supports symlinks. You don't need to ask "does this filesystem support symlinks?", you just use stat() to find out what kind of file this is.
> How about basic or extended attributes?
Same thing. getxattr() will give you the extended attributes, if there are any. You don't need to start with detecting the filesystem and try to figure out if xattrs are possible, just use the getxattr() system call to read the extended attributes. You'll either get some or not.
> Try that with /dev/zero and wait for your server space to fill up. Then download the already uploaded contents of /dev/sdb onto the current system.
Remember when you called stat() earlier to get the file type and see if it's a symlink? That also tells you if it's a device file. So already done.
Let's say you have really dumb programmers who don't know, and can't learn, that you get file information with stat(). Devices are in /dev. Don't copy the contents of files in /dev. You don't have to think about /dev/zero, /dev/random, etc - just know /dev is device files. Our system skipped /dev and /proc. Or just use rsync - it does the right thing by default. If you don't want to USE rsync, spend 30 minutes reading the rsync man page and do what rsync does. Those are options if you're too dumb to use stat().
None of this depends on which filesystem, init system, or kernel is in use - you won't find a bunch if "if filesystem is reiserfs" in rsync.
Back in the day you used to see two types of JavaScript. Dumb JavaScript looked like this:
if(navigator.userAgent.indexOf('MSIE 5') != -1) //we think this browser is IE5 // Can't use document.documentElement.getBoundingClientRect, give up // Code for Safari ...
{
} elsif (navigator.userAgent.indexOf('Safari') != -1) {
rect = document.documentElement.getBoundingClientRect()
Smart JavaScript does this instead:
if(typeof document.documentElement.getBoundingClientRect != "undefined");
{
rect = document.documentElement.getBoundingClientRect();
}
Just see if the feature is available, don't try to guess which browser it is and then try to figure out which features it has bases on the useragent.
Linux is even easier. getxattr() is always there, it always works. If there aren't any extended attributes, it'll return none.
Bottom line: Jack Wallen doesn't know what he is talking about. Nothing to see here, move along.
First of all: the premise of the article is completely wrong: Dropbox isn't actually dropping support for Linux! The author wrote this entire nonsense article, then when "cvoltz" commented and pointed this out, they added an UPDATE to the top clarifying. The update completely undermines the point of the article. Also, the article provides "reasons" that are just generalizations with no technical backing. I won't rebut them because other posters have already done so. Also note that this author does not represent DropBox. So really, there's no substance here.
While there are differences between Linux distros, and yes it can be a pain sometimes (mostly dealing with installation and dependencies, in my experience), none of the items listed are valid examples of those difficulties. The entire article should just be retracted.
This is all bullshit:
For a company to support Linux, they have to consider supporting: Multiple file systems, multiple distributions, multiple desktops, multiple init systems, multiple kernels.
* You do not need to support multiple file systems. The kernel does that for you. Also most people use EXT-something.
* You need ONE deb and ONE rpm. If your build-system would be anything modern this would be done automatically. You could even cooperate with package maintainers from distributions. Beside that it is easy to package something for debian/ubuntu. And I cannot imagine that this is super difficult for Fedora, SUSE, etc.
* For a working desktop-service you do not need to support multiple desktops. You just need a running client service. Furthermore, you just need an open API, people will add tiny applets to ease shit. Also if you support Nautilus and Dolphin (or whatever it is called) then that would support almost everyone. For the rest see open API.
* You do not need to support multiple init system, because it is a user service. It should not run when not logged in.
* You do not need to support different kernels. You link with glibc. Period.
Instead of lying to us, just say the truth. Linux users are few, they often do not use you paid services, and they often use evil Nextcloud setups anyway. We need to make more revenue and cut costs. We also love to take from the OSS community, but we do not really care about them.
> Dropbox is run by retards who have no clue about proper software development.
It is. My phone died on my trip and I had to buy some other quick; went for a cheapo that has 4GB of internal flash, 3 of which are preloaded with OS and various crapware. There's 1GB for user apps and data left. After mandatory updates of the built-in apps and installing some bare essentials (including Dropbox), I still had some 450MB free. I installed Dropbox to download the files I had on the old phone and I would need, like bus schedules at the destination, where network coverage was too dodgy.
Nope. Can't make an 80KB file available offline through Dropbox. You need at least 500MB of space on your device. Free up some space.
Oh, and I don't give a fuck that you still have 14GB free on your SD card. No 500M internal storage free, no offline files for you!
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2