How does domain collecting even work? Don't you have to continuously pay in order to renew your domain ownership? Even if it's $5/year per domain, surely at some point you have to stop collecting.
I'm not a professional domainer, but "a guy with lots of ideas and no time". Every once in a while I thought of some cool idea, struck a name and bought the .com "just in case I have time to develop it".
I initially used Google Sheet to keep track, but it doesn't remind me of renewals, and some info I want to be dynamically updated.
Oh, another thing I use Every.ID for: keeping track of software purchases, esp. LTDs (Life Time Deals --- SaaS but you only pay once). It's literally a category in the app.
I think that was the owner being shortsighted. If the plugin was something that a reasonable fraction of your users would like to have, then very shortsighted.
Not only you had a person that already knew much more about your product than the average potential hire, but a person that probably was interested in your product (and maybe knew what users wanted) too.
I agree. I am most annoyed by the use of maxims with something so subjective and context-sensitive as code. I've read and written code with 4 (and maybe even more) levels of indentation that made complete sense and code with 2 levels that should probably be refactored into only having one.
I've seen people propose things as dubious as a character limit per function body. Most programming languages are so flexible that no matter what guidelines you set for your project, there will still be very bad code that conforms to all of them.
Forcing function splitting by rules is a good example of this. Very large functions are probably doing too much, but where and how you split them matters incomparably more than if you split them at all.
> The reason cited for this was that "a supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync".
Given that extended attributes are available in most of the filesystems used in Linux today, Dropbox still hasn't answered why they decided to go "ext4-only" for a while.
I think what they may not consider is teams that have a small number of Linux users. In that case, Linux support could be required for the team to use Dropbox, even if the actual number of Linux devices is small.
My point being that the 0.1% of sales might be true per device, but "supporting Linux" might actually bring more revenue than just the devices themselves would indicate because the whole team's revenue would be lost if they didn't support Linux.
Doubtful. I work for a major Dropbox competitor and we don't have any Linux support. We aren't loosing any sales over Linux, nor are we under any pressure for Linux support.
Typically Linux support in products like this is organic: It happens when the engineers themselves use Linux and push upwards to support it.
Anyway, with the amount of testing and verification we do on our product, desktop Linux is impractical. We try to verify on as many possible user configurations as possible. (Multiple Windows versions, 32-bit and 64-bit, Multiple Mac versions, remote desktop, ect). Linux is so heterogeneous that we could only really support it if it was a large customer where we targeted their typical configurations.
Not sure who you work for, but I'm going to talk about Box since that is the competitor I'm familiar with. I'm in academia and to my annoyance have to interact with Box which has no linux support (and has also deprecated existing workarounds like WebDAV).
It's frustrating to me because academia is a major target for Box, and there are many of us linux users here. I wish the university admins that negotiate these deals would consider us.
It also feels like Box has a dismissive attitude towards us. Linux support has been a much requested feature for a long time, for example see this years-long thread: https://community.box.com/t5/Desktop-and-Mobile-Forum/Status.... IIRC mods encouraged people to vote for this feature request in BoxPulse, where it subsequently became one of the highest-voted features, but then labeled WONTFIX. Also annoying that Box supports linux-based Android, and also supported the less-used Windows phone. Yes there are a lot of linux distros out there, but Box could put out a snap, or just target one distro and let the other distros patch for themselves (like Steam does).
The problem with supporting Linux, for commercial desktop software, is that it's extremely heterogeneous. Some user might be on Ubuntu, another on Redhat, another on Mandrake; all with very different details.
Thus, what happens is that so-and-so runs such-and-such which happens to be incompatible because of some whacky configuration alignment that no one considered.
The test matrix then becomes much more complicated than a traditional test matrix targeting common Windows and Mac configurations.
That's fine for expensive software where the end user might have a very close relationship with the vendor, but for "cheap" software the cost of supporting every possible way someone configured their computer is significantly higher than targeting Windows and Mac.
(Otherwise, the Linux version of a program might cost 2-10x what a Windows or Mac version will cost.)
I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.
The problem with supporting Linux, for commercial desktop software, is that it's extremely heterogeneous. Some user might be on Ubuntu, another on Redhat, another on Mandrake; all with very different details.
If you are targeting businesses, virtually nobody will run Mandrake (which does not exist anymore), Mandriva, Arch, or whatever. When you target Ubuntu LTS and Red Hat Enterprise Linux, you have probably covered most of the enterprise user base.
(Otherwise, the Linux version of a program might cost 2-10x what a Windows or Mac version will cost.)
This surprises me, because Apple changes and breaks a lot of stuff every macOS release and Apple only supports one or two versions back for security updates. In the meanwhile, RHEL only releases every half-decade or so and supports every release for much longer. Ubuntu LTSes are only released every two years and are then more or less frozen as well.
I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.
Except if you care about servers. Or developers for that matter.
In an enterprise, even Linux on the desktop is standardized and you’re likely to find that the LTS options (Ubuntu LTS or RHEL) will cover most of the Linux users. And those that aren’t covered are probably used to finding their own way, if given the appropriate tools.
Sure, for everyday end users, supporting Linux can be a pain, but if we’re still talking Enterprise, there are only a few distros that would need to be covered.
>I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.
I don't use desktop Linux myself and I'm not usually a desktop Linux advocate at all, but I know that a lot of developers use desktop Linux professionally for good reason. Public administration in Europe is also very gradually moving towards using more Linux on the desktop (in spite of well publicised setbacks). There is a lot of public pressure in that direction.
Desktop Linux may not be important now, but it probably has more growth potential than anything else. And if it grows even just a little bit, the impact on Windows/Mac-only cloud solutions will be disproportionate. It doesn't take a huge percentage of Linux desktops to make Windows/Mac-only cloud solutions very cumbersome.
I think it's a smart move by Dropbox to occupy that niche now, even if it's loss making. There could even be a bit of a moat, because Microsoft and Google both have reasons (Windows/Chrome OS) to drag their feet.
Yes, I have a "free" "unlimited" Box storage via UChicago but I never think to use it since I'm a Linux user and it's such a pain to use from the browser. Supporting Ubuntu and EL would support the vast majority of users on campus.
As a Linux and MacOS user I would never recommend a solution that does not work on Linux, unless it's effectively a free complement to something else the company is paying for.
As a Dropbox competitor I know that you've lost at least a couple of sales because with all the companies I worked thus far the only sync solutions used at the company level are Dropbox and Google Drive. And the later is only used because it's attached to Google Suite, but nobody pays for extra storage.
And all the companies I worked with have some Linux users. And I know, correlation is not causation, but I know that at least one of those companies haven't gone with Box because of missing Linux support.
If you haven't noticed lost sales it might be because companies with Linux users aren't even bothering to check you out.
In enterprise sales, there's often a huge disconnect between who you're selling to, and who is actually using the product.
In which context it might actually be perfectly correct to say that you aren't losing any sales over it, even if there are thousands of users who would use Linux support, were it there.
This very much depends on the product but note that is exactly why I listed other possibilities. If Linux support was a big opportunity they’d know — maybe not precisely but enough to know it was hurting them.
I’ve been using Linux for around 25 years, some of that selling commercial software and most buying. There’s a very noisy contingent of the community who make a lot of noise but never actually buy anything. You’ll go broke chasing their feature requests because there’s always one more thing before they can switch.
It's shorthand for, "We might be losing sales, but we assume they're a negligible amount of total potential revenue", which is a fair assumption to make.
Anyway, with the amount of testing and verification we do on our product, desktop Linux is impractical.
And yet, there are many open source projects have the scale of a file synchronization tool or larger, that manage to work fine (and run a large battery of tests) across different Linux distributions, BSDs, and macOS.
I don't think it is impractical, it is probably just not a good business case.
(I don't necessarily agree, I think Linux users will typically send more fine-grained and useful bug reports and might help you shake out bugs more quickly.)
I'm sure you don't lose a significant number of sales over Linux. The number of sales could probably be smaller than statistical error, and I think your company made the right decision.
But using 'any' as an universal quantification is false, because some users like me are paying for products like pCloud precisely because they support Linux.
Yes, this. I often have this same conversation with restaurants who don’t have gluten free options. You certainly aren’t obligated to do so, but if you don’t have any and there is a single person in our dinner group who needs them...our entire group goes elsewhere.
While this is true, I think a more subtle reason to support Linux is the open-source scripts devs setup that may be mission critical.
I work in a bioinformatics lab, and I access Dropbox through the command prompt and do a lot of file cleanup through scripts for dozens of researchers, which is impossible on Windows or Apple.
This BTRFS reversal last year was a nightmare for everyone's research even though I'm the only one who uses Linux.
Out of curiosity, why is that? macOS does provide a Unix environment and Bash & Zsh shells. (and Homebrew or MacPorts are package managers that can provide updated versions of whatever)
I suppose it's possible in the sense that anything is possible. But, in my experience, Mac versions of Linux tools are not A) Posix compliant, B) outdated, C) don't have the exact same functionality, and/or D) Abandoned.
I use Linux because the scripts are easily moved between the cluster computers and my computers, but I suppose YMMV
> But, in my experience, Mac versions of Linux tools are not A) Posix compliant, B) outdated, C) don't have the exact same functionality, and/or D) Abandoned.
You’d definitely want to use Hombrew: you can get the GNU utilities instead of the BSD ones Apple tends to ship, at the latest versions, and it’s a single command to update everything.
Honestly it's not really feasible to use Python when basic Linux tools like comm, or dos2linux, which take literally just a few characters, recreating the functionality in Python would be a headache.
Yep, I am not a user of any of these services yet... but if I did go with one it would definitely require linux support and knowing I can trust the company wouldn't screw me. Just because the current sales are low does not mean there's no ability to make good future sales.
On the one hand, that might be true, but I doubt that it's true enough in practice. Presuming competent PM's and data analysts, they've likely accounted for individuals vs. teams to begin with.
Even if they haven't and it's literally 0.1% Linux users, I think that it's unlikely a team will pivot on a sale because of a few users who insist on not using ext4. Instead, those Linux users will probably just end up creating ext4 partitions somewhere so everyone can get on with their jobs.
Storage is a commodity like toilet paper. If your preferred brand of toilet paper required you to remodel your bathroom would you do so or buy different toilet paper?
1. Dropbox isn't just storage. If it was just storage, it would never have taken off. The reason Dropbox makes tons of money is because it's actually selling a process. Still commoditized, but it's not as lightweight as toilet paper.
2. If you feel like creating an ext4 partition is analogous to remodeling your bathroom, I would question where you choose to hold strong opinions.
I think you have your analogy backwards. I'd happily switch out the toilet paper brand (the file system on one partition) in my bathroom (how my team and I manage shared documents) if that's what it takes to make the bathroom fit its purpose.
Besides, Dropbox didn't kill Linux support, they scaled it down to ext4, which is a perfectly inoffensive choice of file system for an end user.
Zfs has a lot of features over ext4 its not remotely equivalent.
Replacing this functionality on ext4 requires an entire stack of alternatives. Worse if you opt to use zfs and ext 4 you now need 2 complete stacks or to use an inferior set of tools to be compatible with a commodity service.
I would beg to differ. There are a lot of people / kids using it that don't really understand what is going on under the hood.
Also the number of bugs that get marked as Won't Fix that are real problems by upstream doesn't help so a lot of people like myself just don't bother after a while and just end up using something else or living with it being broken.
yet another explanation may be the fractured nature of the eco system. Every time I look at linux software bug trackers a good portion is distro related.
Multiplatform code when tested tends to show more bugs than single platform code. Also, using different compilers (when it is possible) will help find obscure but real bugs.
In the end this makes the code more robust for all users, not only Linux users.
This has been my experience as well writing cross-platform software (some of it proprietary in the past).
Because different compilers and different stdlibs do things in subtlety different ways, that may just work on one platform by chance. Memory alignment/layout is often slightly different for example.
Then IO behaviour is often quite different on Linux and OS X despite both being POSIX... (and once you need high performance or Async IO, you're using native APIs anyway).
Memory behaviour is also quite different in terms of buffering, when memory gets freed, etc - e.g. on Linux you often need some malloc_trim(0) calls to actually release recently-free'd memory), on other platforms that's not as necessary, so there are subtleties there.
Different platforms often have different includes as well (on Linux, you generally use GCC's STL/stdlib, on Windows it's a totally different set).
Particularly around alignment - it could be that your compiler is emitting instructions that can deal with it, but in a sub-optimal way such that there is a performance penalty. On other platforms, that sort of behavior may cause a compilation failure, or the bugs they cause create bigger (and more noticeable) issues.
I understand this. Think more along the lines of "If a tree falls down in a forest, does it make any sound if there is nobody there to hear it?". If there is a defect on Linux, but nobody is running it on Linux, is there really a defect?
It's quite possibly a silent bug on the other platforms as well (i.e. relying on undefined or compiler-defined behaviour that just happens to work currently).
A new compiler / OS update / graphics card driver in the future might trip the bug on the platforms it seems to be working fine on currently.
Lets pretend a few things, because I don't think you understand what I am getting at. I have application called "Music Box", I am release version 2.0.0 and it is QA'd before release against Pear OS 7.0.
If Pear OS 8.0 is release a month later and breaks my application because of an API change their end. I would just release 2.0.1 of Music Box that fixes the defects. If I was proactive get hold of a beta or release candidate of Pear OS 8.0 and QA my application on there to see if there was any obvious defects.
The same with a newer compiler or a newer hardware driver. I would just get hold of the beta / release candidate and fix it then. The one thing I wouldn't do is try compiling it on a completely different OS that none of my users use.
> Relevant discussion: “Linux users were only 0.1% of sales but 20% of crashes and tickets”[1]
Might be fair to note that these numbers are for a video game, not a file syncing app. Linux is relatively new territory there, let's say when Steam started supporting it.
I wish it worked it self out with community patches - more likely is a github mega issue, with people suggesting their forks as solutions if the original maintainer doesn't reply for 24 hours, or during the UTC+8 9am-5pm window.
> The operating system is delivered in images that are created by utilizing the rpm-ostree project. The main benefits of the system are speed, security, atomic updates and immutability.
The article never mentions speed (or performance) again. Is the OS somehow expected to be faster because it is mounted read-only?
No, I wouldn't expect this system to be faster in a meaningful way. Actually maybe a bit slower since fewer libraries will be cached / memory mapped between applications if they carry their own copies.
When you're running a GUI those libraries also get shared. For example Qt might not be used by as many processes as libc, but it saves hundreds of megabytes of memory having that shared across my email/calendar/terminals/torrent client/windowManager/guiShell/pdfReader/webBrowser.
The GP did mention the 'big graphical ones,' but the amount of memory that gets saved was a bit stunning the first time I saw it.
That's a good idea to measure the sharing! Fortunately even if every app gets containerised, not all of those libraries will be duplicated. Specifically each app which forks on its own will still preserve sharing. For example 11 firefox processes I'm running now would share the libraries, whether it's running directly or from docker.
Flatpak has a notion of runtimes, that are shared among applications. All the shared libraries in these runtimes will share their mmaped regions.
On top of that, ostree does deduplication based on file checksum. So if different packages ship the same binary, it will be only one copy on the disk and again, the mmaped regions will be shared among processes.
Even when the processes are loading the libraries from different paths, in different filesystems, in different containers? How does it page in data on demand if the first container that loaded the library is killed and its filesystem unloaded?
It's not easy to share libraries across containers, unless they can be built to share a base layer in a stacked union filesystem approach.
>Even when the processes are loading the libraries from different paths,
Well, in my original post (GGGP) I've defined "a library" as "a .so file" so what I can say is that the 872 distinct .so files used on my laptop will be shared among the different processes that use them.
If you assume the same library can be duplicated in two different .so files, then 872 is just an upper bound on the number of distinct libraries and further sharing could be done.
Eitherway, that is a significant amount of code sharing, which was the original question in this thread.
Only if they're the same version (which using the older built-in package system all packages are likely built against the same version)...
If the containerised versions of apps all have different versions of dependencies (quite likely IMO as they'll have the freedom to), there won't be any sharing.
Or even different locations. (unless they're hardlinks, or COW files probably) If it's not the same block on the disk, it's going to be duplicated in cache - whether it's the same contents or not.
I agree that JS is not substantially "worse" than some other languages.
Despite these three languages giving far too much freedom to the programmers (which some might even like), high-quality code can be written in all three of them, as long as intelligent and strict coding guidelines are thoroughly followed.
I always think of languages as a solution space, and some points in the space possessing bugs while others don't. A perfect language(impossible) would make it so you could write any correct version of a program in the language but not any incorrect version. And language constraints like static typing have the disadvantage that you're preventing a bunch of correct possible solutions while closing off incorrect solutions. Ideally closing off many more incorrect solutions than correct ones increasing your chance of landing in a correction solution.
And of course lots of out of band(non-language) processes and tools that influence this like unit testing/code reviews/strict coding guidelines. But it's always nicer when it's prevented at the language level as opposed to out of band.
I enjoyed the article, and I know that writing these takes a nontrivial amount of time. So I think it would be wise of you to run these through a spell checker before publishing, as this is a less than a minute investment which pays off every time someone reads it.
> Google certainly doesn't seem to value feedback at all.
As it is with most big companies that profit from ad revenue. They seem to consider performance indicators to be sufficient to know if a new feature is good or bad, instead of worrying about written customer feedback.
