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.
I thought Slashdot of all places would be free of the old Microsoft FUD from the 90s about how supposedly fragmented Linux is and how Linux users don't want to pay for software because Linux itself is (usually) free... The reality is that from an application developer's perspective Linux is about as fragmented as Linux and OSX if you can use some pretty basic principles and Linux users do pay for software if good paid software is available. It's also kind of ridiculous for SystemD to be brought up here when application developers don't need to work with it and it's pretty much universally used at this point.
But hey, gotta bait those clicks somehow right?
"Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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?
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®.
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.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
You can always statically compile your libraries in, especially those that might end up being problematic.
If that's the case then explain systemd. /s
Easy; systemd is not the unix way.
For the GUI you have to give them that, they have a valid point. Everything else is just bollocks though.
I only please one person per day. Today is not your day. Tomorrow isn't looking good either. - Scott Adams
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
rsync was a Unix tool. So it was probably designed around the Unix design principals. While Dropbox was a hack design to Windows.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
...or I'll just switch to any other of dozens of cloud storage services.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Because of course the better product always wins in the market.
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
If something is so important that you feel the need to post it on the internet... It probably isn't that important.