What Dropbox Dropping Linux Support Says (techrepublic.com) 424
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.
Why is the FS a problem? (Score:5, Interesting)
Surely the OS is providing standard access to every FS, so from an application perspective everything looks the same. So why is it a problem for applications to support ext4 and btrfs when, via the OS, they should look the same?
fopen() will still work, regardless, surely... no?
Re: (Score:2, Informative)
Except Dropbox wants access to your filesystem details for their backup stuff., not just the file descriptor and data.
Re:Why is the FS a problem? (Score:5, Insightful)
Except Dropbox wants access to your filesystem details for their backup stuff., not just the file descriptor and data.
So, in other words, Dropbox is run by retards who have no clue about proper software development.
It's a program that copies files from one location to another. If Dropbox can't get out of the way and let the OS worry about things like the file system and systemD, then there is something seriously wrong with them.
This is a classic case of Doing It Wrong®.
Re:Why is the FS a problem? (Score:5, Insightful)
This type of design is what I find is what developers make when they are at the "Arrogant Rookie" level of their career.
Where if there was a book on the technology, The skills used are from chapter 1 and the last chapter.
They are trying to show off how good they are by not doing things the easy way.
I had once had to maintain an application because the developer who decided to access a database not via the SQL commands that it supported, but by directly accessing the DLLs and doing the direct calls to the database engine.
Yes it was faster, but this product was so tightly tied to the Database system that it was nearly impossible to upgrade the database engine, and were at the direct wims of the Database Company, if they charged more then we had to pay more, or do a near full rewrite of the application. As well if there was a bug in the code, then the entire data would get messed up because of the low level access. As well it skipped steps to make the data SQL compatible so it required either a hex editor or custom programming for any ad-hoc report, or odd data fix.
Normally if a company or a product seems to be very strictly worried about low level differences, chances are it was coded by an Amateur who thinks himself all that. And is a sure sign to avoid such product on all environments.
Linux means DIY, so DIY (Score:2)
Linux users always boast of being able to configure their systems any way they want. Making it interface to Dropbox is just one more configuration issue.
You just need to make your Linux box look like a Windows box from the outside....
Re: (Score:2)
Linux users always boast of being able to configure their systems any way they want. Making it interface to Dropbox is just one more configuration issue.
You just need to make your Linux box look like a Windows box from the outside....
Yeah - Linux users. This is like the rookie mistake that we've been talking about. Linux, like all other OS' consists of all manner of abilities among the users from tools like me who are about 3/4's along the expertise level, to my wife, who is at "Grandma" level, but happy running Linux Mint.
Re:Why is the FS a problem? (Score:4, Insightful)
It does sound like it, but I have made my career taking over other peoples work. While I see a lot of things that I think I could do better, I can see the logic behind the approach especially with the time such product was made.
However I also have been able to meet the people with the code I am taking over, They seem to fall in categories.
"Not my job, but it needed to be done": This is code from someone who didn't want to make an application, but just kinda grew out of hand. Oddly enough besides some infrastructure problems the code is rather clean and logical.
"Arrogant Rookie": The guy who thinks he is all that, however while trying to make impressive stuff, really fails on understanding. This is usually the toughest code to figure out, because the easy way to solve problems seem to be consciously ignored.
"General Pro": They are a professional, their code tries to make sense, and the code it normally easy to follow. Sometimes they have some bad days, but in general easy to follow and fix.
"Rockstar Developer": The code is actually kinda OK, however perfection often makes their code dense at time, and difficult to maintain, until I can figure what is going
Re:Why is the FS a problem? (Score:4, Informative)
> 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!
Re: (Score:3, Insightful)
...or I'll just switch to any other of dozens of cloud storage services.
Re: (Score:3, Insightful)
Because of course the better product always wins in the market.
Re: (Score:3)
So, in other words, Dropbox is run by retards who have no clue about proper software development.
It's a program that copies files from one location to another. If Dropbox can't get out of the way and let the OS worry about things like the file system and systemD, then there is something seriously wrong with them.
This is a classic case of Doing It Wrong®.
AC needs to be at +5.
This also smells a bit like a zealot is in charge.
Re: Why is the FS a problem? (Score:5, Insightful)
rsync was a Unix tool. So it was probably designed around the Unix design principals. While Dropbox was a hack design to Windows.
Re: Why is the FS a problem? (Score:5, Interesting)
These are rare corner cases though, and not really a problem with rsync or the filesystem. By default rsync compares datestamps to check for changes and will skip over files where the datestamps match. Sometimes a file will be altered but its datestamp won't - the only situation I'm aware of like this is Linux filesystem container binary files. In my rsync scripts I have to touch each of them first if I want them to be seen as updated. Somewhat more commonly there are a few programs that will update the Modified datestamp on files they open even if they've only been read and not changed.
I blame the way these programs handle datestamps. Linux/mount should update the datestamps of filesystem container files when they're written to, and programs shouldn't update the datestamps of files that are not changed.
Re: (Score:3)
Re:Why is the FS a problem? (Score:5, Insightful)
That exposes a basic misunderstanding of how software in Linux is built. The program which presents a remote filesystem should be separate from the program which synchronizes files. That's the unix way.
It also makes Dropbox's job simple: a fuse (filesystem in userspace) driver and then let folks stack whatever other Linux software they want to on top of it.
Re:Why is the FS a problem? (Score:5, Interesting)
That exposes a basic misunderstanding of how software in Linux is built. The program which presents a remote filesystem should be separate from the program which synchronizes files. That's the unix way.
It also makes Dropbox's job simple: a fuse (filesystem in userspace) driver and then let folks stack whatever other Linux software they want to on top of it.
Yeah, I was confused about that argument about fractured filesystems (among other things) in the original post. How and why does that matter to them, unless they're doing something at a lower level than userspace?
Yes, I agree, the Linux community is horribly fractured and must be a big nightmare for some applications to be ported. But if it's available for anything Apple, or anything Android, porting it to Linux should be relatively easy.
From article:
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).
Mostly because we're accustomed to having enterprise-grade software free. Linux users aren't cheapskates, and consider that ALL the computers in the TOP500 list are running Linux. Linux users can shell out money.
I'd be a lot more receptive to AutoCAD, for example, if they put out a Linux version. But why bother? There's FreeCAD and a host of others. Photoshop? GIMP. And let's not even get going on Blender.
Dropbox - isn't it, really in the end, just rsync being run within a script? I liked the name for the credibility, but again, Linux has credibility in its own right. [wikipedia.org]
Re: (Score:3)
Yes, I agree, the Linux community is horribly fractured and must be a big nightmare for some applications to be ported. But if it's available for anything Apple, or anything Android, porting it to Linux should be relatively easy.
If that's the case, why is there no openbsd variant?
Windows is pretty fragmented too, look at the issues with various AV software. PowerShell is starting show signs of decay through the lack of consistency from 2008 versions onwards, (see cmdletbinding for example).
Re:Why is the FS a problem? (Score:5, Insightful)
If that's the case then explain systemd. /s
Easy; systemd is not the unix way.
Re:Why is the FS a problem? (Score:5, Interesting)
Re:Why is the FS a problem? (Score:5, Informative)
"2 Types of Linux File Locking (Advisory, Mandatory Lock Examples)": https://www.thegeekstuff.com/2... [thegeekstuff.com]
This might be of some interest to you.
Re: (Score:3)
I rarely every have file locking problem in Linux systems. Unlike windows Linux was designed to Mimic Unix principals and Unix systems were designed to be multi-user environments. Having multiple Apps accessing the same file is rarely an issue. Especially with one app which job is to write and the other one whose job is to read.
Re:Why is the FS a problem? (Score:4, Interesting)
In my own experience, you are correct. In my own work, this is true.
From the perspective of one shuttling a file from this place to that without any concern about its content, buckets of bytes are buckets of bytes. The files system says "I prefer moving blocks of 4096", I say okay, gimme 4096 of 'em this time and I'll keep asking until EOF.
OTOH, from the perspective of one parsing those files for meaning, the situation becomes far more complex and our suspicion of their motives should increase.
Re: (Score:2)
Re: (Score:2)
and third, you read it up to your allowed quota and then stop, 'storage space exceeded', bye. If a user really, really wants to shoot themselves in the foot, let them. You have no valid reason to place the /dev/zero pseudo-file in your Dropbox directory.
Took me a day to get it right. stat() and getxattr (Score:5, Informative)
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.
Re: (Score:3)
Say a file originated on a computer whose file system with extended attributes and in fact has extended attributes. You want to sync it to the computer you're using, whose file system does not support extended attributes. How should the sync tool store the file on the computer you're using without removing the extended attributes when syncing it back?
Re:Took me a day to get it right. stat() and getxa (Score:4, Interesting)
Because that has never been a problem before, when dealing with oddball solutions of past filesystems. Deal with it the same way - a metadata file that holds the crap that the filesystem doesn't deal with well.
For example, we've all seed the .DS_Store files on any fileshare that a Mac has visited, which holds Finder metadata that would be written to the HFS file system if it were HFS, and otherwise sits in a metadata file everywhere else. No, it's not the cleanest way to work, but it's something that Dropbox could implement in about two hours and be done with it, because this is a long-solved problem, and we don't need a new shaped wheel.
Re: (Score:3)
Basically everything in the standard C library works. You only run into problems when doing non-portable things. I guess Dropbox does not have the money to hire a real Unix developer...
Re: (Score:3)
The stdio library is insufficient for the performance and handling they do.
Bullshit. The standard library is sufficient for anything the machine can deliver in performance. If they claim need more, then they have some severe design defects in their system.
Re: (Score:2)
I thought something similar about the "multiple kernels" bit. Because each version of Windows has a kernel that is at least as different from the others as you find in varying Linux distros. Yet, you don't see most software companies fretting about the versioning of the Windows kernel. Same for the multiple desktops: pick a widget set (GTK or Qt are popular) and that is about all you need.
I think the case of Dropbox is perhaps slightly different, as they might need to do lower level FS access than most t
Re: (Score:2)
If you are a userspace application (which are the *vast* majority of applications), then the multiple kernels and multiple file systems don't matter. If you touch the kernel, the diversity of the kernels may be at some level equivalent between Windows and Linux, but Windows has a certain set of sensibilities about kernel API and ABI, but in Linux APIs and ABIs can change at will. Source code that compiles under RHEL 7.4 might not compile against a 7.4 hotfix kernel (though in RHEL, ABI is such that the ol
Re: (Score:3)
This seems to be a higher up with no idea on the technology coming up with some sort of excuse to not support Linux.
Do they spend the time developing support for ext4, btrfs, Ubuntu, Fedora, GNOME, Mate, KDE, systemd?
For most applications even rather complex ones The file system is rather transparent, Unless you are really wanting to focus on some unique feature of the File System, say restore to a previous file version, but still for most cases these extra features and tools are reserved as part of the OS
Re:Why is the FS a problem? (Score:5, Interesting)
They are trying, and largely succeeding. Nevertheless, all non-trivial (and filesystems are highly nontrivial) abstractions are leaky [joelonsoftware.com]
A service that offers background sync (i.e. changes are pushed to the cloud in the background) which doesn't just poll (polling is evil) needs an API much more complicated that fopen. Specifically, it needs a notification stream where it can create a 'watched' folder and be notified when:
This is a (somewhat) solved problem, in the sense that inotify [wikipedia.org] exists within some limitations described on the wikipedia page (and further in the man page [die.net]). One really obvious limitation is that the kernel will not do this recursively for you, meaning that the client has to manually add/remove folder watches. The other is that rename events are clunky, coming in two halves with a linking identify. Anyway, if you read the history [lwn.net], you'll note this is the third or so attempt at getting this right, which at least suggests that it's non-trivial enough that we had to can the original (dnotify) interface and start over once.
What was the point of this side-track into filesystem watching? Well, for one, we started with "how hard is fopen/fread" and now ended up with "holy crap, that's highly non-trivial to be async notified of changes within a directory tree (recursively!)". It also raises the question of whether the interface really is an airtight abstraction, or whether filesystem implementation details leak into the caller to be dealt with. Even answering that question for all supported Linux filesystems is non-trivial.
If you take nothing else away, just remember that this is a far more complicated problem than rsync ;-)
Postscript: rsync is 50K LOC
It's not the FS, it's not the "free" mentality... (Score:2, Interesting)
The problem isn't the file system. It isn't multiple desktops. It isn't the fact that Linux users feel entitled to free (as in beer) stuff. It's the education level of Linux users.
As much as Linux has tried to make inroads with the common joe, the general Linux user still displays a higher level of computer competence than other platforms. Which means they are less likely to put up with Dropbox's shenanigans when they do stupid things to make you pay.
Example: Bob has used 1.5 out of his 2gb of free spac
Re:Why is the FS a problem? (Score:5, Insightful)
That is my thought. It was just FUD way to explain they just don't want to do it.
Other then saying all these "technical" difficulties. They should just state that it is difficult to support Linux, because it is hard to train Level 1 India support to navigate a non-standardized UI.
I guess this won't be the year... (Score:5, Funny)
...of Linux on the DropBox?
Are you retarded? (Score:5, Interesting)
Why would an image editing program give 2 shits about: ext4, btrfs, GNOME, Mate, KDE and systemd?
Re: (Score:2, Insightful)
Or, more than that, if they're down in the weeds that far to squeeze out every bit of performance possible, why wouldn't they just state what they require and do a simple check to make sure it exists before installing... like any other application ever?
Re:Are you retarded? (Score:4, Insightful)
Re: (Score:2)
For the GUI you have to give them that, they have a valid point. Everything else is just bollocks though.
Do you mean GUI libraries? That you mostly have on all platforms (there may be a default, but there are many non-default options, and defaults change and get deprecated on Mac OS and Windows).
Desktop environment? Nonsense. I have never had a real problem running any KDE apps on GNOME or Icewm or whatever else (or the other way around).
And many proprietary apps (Spotify, Skype, Visual Studio Code etc.) don't seem to have any problems with this ...
This old FUD? (Score:5, Insightful)
But hey, gotta bait those clicks somehow right?
Re: This old FUD? (Score:3)
Dropbox has a daemon component for file syncing so startup scripts are going to be involved.
Re: (Score:3)
Re:This old FUD? (Score:5, Interesting)
Dropbox made some really dumb design decisions early on, tying the program way deeper into the OS works than it really needed, and suddenly they discovered that if you dig all the way through the one uniform friendly abstraction layer meant to be used by everyone and sufficient to everyone, you suddenly discover there are many different variants of works down below, of things you weren't supposed to touch in the first place. And they change a lot, and are hard to use.
And now they try to pin the blame on someone else.
Re: (Score:2)
Strange that software have to be ported among distributions then, maybe you should realize that you as a user isn't likely to notice the hidden work of the developers?
"There is no and have never been any fragmentation in Linux or among Linux users! Never!" - The Baghdad Cynical Critic
Re: (Score:2)
And alternatively, they could just code cleanly (Score:5, Insightful)
There is a ton of applications on Linux that all do not have these problems. It just requires a bit of experience and not using every damned feature some specialized installation may have. Apparently, Dropbox is lacking the skills for that though.
Re: (Score:2)
It just requires a bit of experience....
Apparently, Dropbox developers never bothered to learn how to create an API. My guess is that this all appears so hard to them because they never learned the simple lessons of encapsulation and polymorphism.
Re: (Score:2)
Yes, quite possibly. Incompetent hacks.
Re: (Score:2)
Or maybe they don't care and they just wanna make cash. Not everybody has emotional attachment to their job.
Re: (Score:3)
Poettering is just another incompetent with a big ego. As such he is not special in any way. The problem is that some morons decided to pus the abominations he creates onto the world.
Re: (Score:3)
And when I download a source package (not distro-specific) and compile that, I usually do have not have these problems either. Sure, there is bad software in the FOSS landscape, and quite a bit of it, but the good stuff shows that this is not a problem of the platform. But you have a valid point, even if indirectly: Many Linux users do not know how to compile stuff from sources these days.
Dead in the long run. (Score:2)
Don't support Linux, and you'll be dead in the long run.
Re: (Score:2)
Don't support Linux, and you'll be dead in the long run.
Huh?? SUPPORT Linux, and "you'll be dead in the long run." You'll be dead in the long run ANYWAY, it's the short (usually every quarter for public companies) and maybe mid-run that usually gets people's attention.
BTW, the dinosaurs didn't support Linux either, and look where it got THEM -- they're all dead. So I guess you're right after all.
Re: (Score:2)
But they would die out even if they did support Linux.
Re: (Score:3)
I think "support" is the key problem. Developing a product for Linux is easy, the excuses given were lame. The real problem is Supporting the product.
Linux is difficult to support at Level 1 and Level 2 support, which is just the support people reading the scripts, then watching the person follow the items on the script. Ubuntu and Mint technically are nearly identical. However the UI is a bit different. So the script needs to be a little different for each one. Level 1 and 2 support has nearly 0 brains
I'd believe this, except for (Score:2)
the whole android is linux argument.
I don't see dropbox abandoning android support in the summary.
The good news? I'm sure there will be something to replace the client published in the near future.
Linux is a moving target (Score:2)
Let's say I made a complex image editor for Ubuntu. The following month it stops running because the lib "X" no longer supports for something that I assumed would be standard. Then it's the "Y" lib that crashes because the lib developer decided to rewrite it in a scripting language (and did a mediocre job at it). I as a responsible professional spent a few weeks changing my code (and this costs money) to get aro
Re: (Score:3)
As of version 10, Windows is also a moving target.
https://www.microsoft.com/en-u... [microsoft.com]
If you're only worried about Linux being a moving target because you write poorly-coded crapware, then good news! Windows update always breaks SOMETHING on all the poorly-coded crapware IT installs on my work desktop. Seriously. Every. Time. It. Runs.
Linux is the new normal.
Re: (Score:2)
Re: (Score:2)
I have no problem creating logical arguments, thank you... But, you on the other hand did not understand that the subject should be responding to me instead of the article, so i think is you who have trouble creating logical arguments and also problems with text interpretation.
Re: (Score:2)
Yet the Windows API has been stable for a long time. And even device driver frameworks such as KMDF and UMDF have been stable for a long time.
Re:Linux is a moving target (Score:4, Insightful)
You can always statically compile your libraries in, especially those that might end up being problematic.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
It's not good enough (Score:2)
I think this thread explains the situation perfectly. All the potential users of Dropbox on Linux already know that:
1. Dropbox doesn't hire good developers or else this would be a non-issue
2. Dropbox are trying to back door the system, and if not show us the source and prove it.
That reduces their possible audience of happy customers to 8,000, all of whom are on corporate Linux deployments in Germany aren't aren't allowed to install Dropbox anyway.
Meanwhile:
1. Dropbox works really well.
2. WSL already.
Sorry, but this is nonsens. (Score:5, Insightful)
Let's take the case of Adobe porting Photoshop to linux.
1: ext4/btrfs - This does not matter at all. There is no case where photoshop cares about the filesystem it runs from.
Ubuntu/Fedora - Not really a problem. I personally run Fedora, but fedora don't have any problems running binary software developed for Ubuntu. Case in point: Most of the games I have in my Steam library are developed for Ubuntu, and have newer been tested on Fedora by the devoper at all. But they still run fine on Fedora.
Gnome vs Mate vs KDE - Again: Why should Photoshop care? None of my other apps really care so why should Photoshop?
Case in point: Even if I replace Kde which I currently use with a version of Enlightenment which I have compiled my self, none of my software will stop working. Apps don't care.
systemd: If Photoshop cares about my init system, something have gone really really wrong. No issue at all.
Re: (Score:2, Interesting)
Re: (Score:3, Funny)
systemd: If Photoshop cares about my init system, something have gone really really wrong. No issue at all.
Here's where I think you have gone wrong. It's not that Photoshop cares about systemd, it's that one of systemd's goals is to overtake everything and in the process subsume Photoshop.
Emacs is also on that list, but the timeframe for that is an order of magnitude later.
Re: (Score:3)
This is, sadly, true. systemd hs repeatedly burdened us with modifications of basic system functionality, such as when it started killing processes owned by users who had logged out. This broke "screen", "tux", and "nohup" for backgrounded operations. However, systemd also does system logging. So any daemons created by installing commercial Adobe Photoshop, such as a license daemon, would typically use systemd logs.
Re: (Score:2)
Filesystem, agreed, that's dumb to bring up in the context of Adobe software.
Ubuntu/Fedora - While the code is likely to be able to work, it does suggest a bigger testing and packaging effort.
Agreed on desktop environment. It *can* matter, but only for certain fringe environments that either can take care of themselves or at the very least know they only have themselves to blame and don't make a big fuss.
Agreed on init system.
Photoshop is a *terrible* example of a project that would be affected by the proli
adobe CC DRM system will need to work on linux (Score:2)
adobe CC DRM system will need to work on linux in a way that can't be easily bypassed
PS has one format. Dropbox needs every format. (Score:2)
There is no case where photoshop cares about the filesystem it runs from.
This is because the Adobe Photoshop file format doesn't use alternate data streams or extended attributes. Dropbox, by contrast, has to sync arbitrary files created by programs that may use these optional file system features.
Re: (Score:2)
Hardly an issue at all (Score:2)
That's a troll article if I ever saw one (Score:2)
Re: (Score:2)
I disagree with their assessment (it's not as bad to support linux *and* you can largely ignore most distributions and still be better situated than ignoring it entirely).
However I will say that free software has a significant advantage, to the extent possible they declare the software to be 'as-is' without warranty and disclaim liability. Commercial software may be on the hook for damages in excess of the revenue from the user.
FOSS pawns off distro integration to the distros (Score:2)
One difference is that a free software developer can often get an application packaged in the major GNU/Linux distributions' repositories, where fans of each distribution will do much of the integration work to keep an application running under that distribution. Proprietary software doesn't have that luxury.
Python (Score:3)
And if VS Code can be written in Javascript and run on Linux, why would it be so hard for Dropbox?
Alternate data streams, for one (Score:3)
Visual Studio Code works with primarily text files and perhaps executables. Dropbox has to be able to sync any file, including files that contain alternate data streams and extended attributes. That's a bit more of an involved job.
Re: (Score:2)
A bunch of Dropbox features are written in Python; it's a layer on top of the base engine. Mostly bloat you really don't want and don't need but they felt they needed to fix what wasn't broken and kept adding that shit.
You have FUD on your shoes (Score:2)
You have FUD on your shoes and now you're traipsing it all over my nice clean carpet.
If you're a company that produces a product and you stake your living on that product then you hire somebody half-way competent and these issues are just totally non-issues.
If Adobe wanted to port their industry-leading product to Linux, how do they do that?
They write code in a portable way and compile it for a Linux target. it's really not hard. For more information, see any of the ten thousand "writing portable code" guides. As a bonus, portable code tends to be much cleaner and is less likely to have iss
Why the hell do they care about filesystems? (Score:2)
What the fuck.
Read file, write file, check timestamp. That's all Dropbox needs. All filesystems provide this through uniform OS calls. Why in the world does Dropbox care what filesystem it's running on? Where in their twisted designer minds did they come up with features that dig so deep below the basic userspace abstraction layer they'd rather lose users than just keep things simple.
Roll your own (Score:2)
Thanks for telling me what to think (Score:4, Insightful)
Linux is primarily used as a web server, as heavy corporate back-end infrastructure, or by hobbyists/enthusiasts. Dropbox's primary market are consumers on Windows, which only has the features you buy from someone, or the mobile market which needs, I guess, a place to store and share their dick-pics.
Nothing about a web server should want to have anything to do with drop-box. It's already public, and drop-box has their own web server.
The corporate world is highly allergic to drop-box as an enterprise storage medium. They all have other ways or other deals in place for any cloud storage they need, and it's not going to be public, nor part of their back-end infrastructure. Even for their end windows users, dropbox is usually forbidden under pain of termination.
Hobbyists/enthusiasts realize their linux already has scp (all the distributions at this point), and so does any machine they may use. So they have DIY dropbox. Add in that this particular market is somewhat more distrustful of cloud-anything, and often has a more privacy and "my data is mine" and "my personal information is mine" bent and the pool of good customers here gets pretty small.
So you have an OS that isn't going to ever be a big player on your product, and you're hurting for cash. So you can fire some devs and drop support for Linux. That's what I think this means.
Article is nonsense (Score:5, Informative)
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.
Linux users are more difficult to spy on (Score:2)
So, let's drain the applications around them and force them to go to WIN10 spyware.
If that fail, let's build spyware and troyan systemd in the Linux, that will do.
Really, all company distros switched to systemd at the same time ?
Plenty of man hours to develop a complex, bynary only, piece of SW that literaly take over the machine ?
There is only one answer.
Chicken vs egg (Score:2)
Let's consider Adobe (and Photoshop). If Adobe wanted to port their industry-leading product to Linux, how do they do that?
They don't. The potential number of paying customers on the linux desktop platform in total is in most cases too small to justify the effort even if somehow they could mitigate the problem (and cost) of supporting the multitude of different distributions. I honestly wish more companies would support linux directly but I understand why they don't. There simply isn't enough profit to be had to make it worth the bother for them. I'm not sure there is an easy answer to this problem.
That's not to say every Linux user is unwilling to shell out the cost for a piece of software. But many won't.
The word you are looking
What Linux? (Score:2)
It says that there's no Linux to speak of. When you're talking about any other mainstream OS (Windows, MacOS, iOS, Android) - they all have: 1) Universal packaging mechanism 2) A set of stable APIs/ABIs you can rely on 3) Some sort of UI stability.
All these these features are basically a swear word [altervista.org] in the world of Linux distros.
LOL Cats... (Score:4, Funny)
P. B. Lecavalier • 7 days ago
I wrote a detailed comment demonstrating how this "award-winning" author has seemingly no idea of what he's talking about. It was swiftly deleted. Fine. I'll leave you with your spectacle of illusions.
Lame excuse for we see our audience elsewhere (Score:5, Informative)
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.
Adobe can't do for Photoshop what open-source can? (Score:2)
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?
Dropbox has this problem with filesystems and encryption layered over filesystems because they want to be a filesystem. They don't seem to have a problem with systemd vs. upstart, or GNOME vs KDE, or Ubuntu vs Fedora.
Photoshop doesn't need to be a filesystem, so they should have 0 problems due to supposed "fragmentation", just like:
* Gimp (https://flathub.org/apps/details/org.gimp.GIMP)
* Darktable (https://flathub.org/apps/details/org.darktable.Darktable)
Oh, you want proprietary examples, well how about:
* S
Linux Desktop Fails (Score:2)
It's like every bad message board post ever. (Score:3)
The op is like every poor excuse I've ever heard on a Linux message board. Let's go through point by point and talk about some of this.
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.
No, that's simply untrue. Nobody in the commercial world supports all of Linux in this way. In fact, I don't know of many oss vendors that do either. If you're going to support Linux, what you're usually talking about in the real world is some major implementation of Ubuntu, and/or Cent/Redhat. That's it. Yeah, you really do need to think of it as two operating systems, because of differences in the package manager, but it's not terrible. It can be managed.
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?
Actually, they did it with Wine. Wasn't released but they did talk about having done it.
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?
My hope is that if Any Given Company were hiring people, and talking seriously about a project like this, that they would have actual Linux people who have experience in developing commercial projects for Linux. Even an entry level Linux developer straight out of highschool programming class could tell you the whole argument is bullshit.
That said, no, I could care less what Dropbox does.
Ignorant article. (Score:3)
The story is ignorant, and apparently written by someone who doesn't know squat about Linux. There is FUSE which is a stable way to add a filesystem driver. The desktop environments and file managers are irrelevant because they use the same filesystem API, and the same API for an app to draw to the screen (X and Wayland). You can use either Qt or Gtk for your GUI application, and it will work on any of the desktop environments. If you write your app for Qt it will run perfectly well on a Gnome desktop environment, if you write in Gtk it will run perfectly well on KDE, because they use the same underlying X or Wayland API. I don't know how many times this has been expained to tech journalists over the years but they still can't get it through their thick skulls. The filesystem variety is also irrelevant becuase the filesystems also support the same filesystem APIs. No userspace software should directly interact with a filesystem. We have flatpack, snapper, appimage, and docker for cross distro packages so that need is being covered. Because systemd supports Sys V Init files, you can use Sys V Init files to start a service and it should work on most distros, systemd or not. The service command is supported by most distributions. So increasingly there are cross distro common denominators for people who are writing applications. The variety of distros, desktop environments, filesystems and init systems is a strength, but there can exist a lowest common denominator cross compatible interface for applications to access.
Re: (Score:3)
Thanks for the informative post!
Re: (Score:2)
...
I'll try to explain under assumption that you aren't trolling.
Multiple file systems: Windows as used in real world systems use NTFS, ReFS with optional and probably not relevant exFAT, FAT32, (FAT16, FAT12 - if that's still supported).
Multiple distributions: the differences aren't relevant other than the use of ReFS.
Multiple desktops: doesn't exist.
Multiple init systems: doesn't exist.
Multiple kernels: the likelihood that Dropbox uses anything that changes between the supported kernel versions is pretty
Re: (Score:2)
Re: (Score:3)