I don't see why any of this wouldn't be possible with text logs. Yes, you can write GUIs that parse text log files. Yes, you canwrite an utility that does all the grepping and sorting for you. Yes, you can filter out logs from the previous boot. I don't think the performance loss would be noticeable.
So your arguments in favor of binary log files seem quite moot.
Oh, I can see you are quite new to Linux log files, they are basically free form dumps of whatever anything wants to write to syslog in any which way they please. It is impossible to make anything else than a crude GUI; a 'less' just with windows decorations. This is exactly why both Gnome and KDE dropped their previous attempt on making such a GUI.
So, how does making it a binary blob help?
The data sources will just produce free form dumps as before, and that's what will end up on the logs.
The things that are structured is the time stamp, facility and critical/error/info etc level, and they are easily parseable anyway.
So either the binary blobs don't help at all, or all Unix applications will be forced to adopt some non-Unix structured logging. For my applications, I can say right now I will not do the changes needed to achieve the latter...
What I wish was available was a way to view the source of a git with one minor enhancement - the ability to browse with a click to the declaration/definition of functions/variables a la the IDE of your choice. Would be neat to be able to build an index using some tool, check it into the root of your repo, and then have the site use the index to mark up the source code with the appropriate links.
I've dug around for something that does this but haven't found anything suitable - anyone know of anything?
Sounds like plain old etags/ctags.
You may have to look at the commit from inside your editor though for that to work, e.g. an Emacs M-x shell.
Honestly, if your compile times are that much, and that much of a burden, you need to upgrade, and you also need to modularise your code more. The fact is that most of that compile time isn't actually needed for 90% of compiles unless your code is very crap.
Hint: I said 'two hours to compile from scratch'. You can't avoid compiling all your source if you just did a clean checkout from SVN into an empty source tree; as you would, for example, before building a release or release candidate.
That, to me, sounds like "I don't trust my build system to do an incremental build". A lot of people don't, and end up spending $$$$ on building provably the same thing over and over again, dozens of times a day... Stop doing that, and you can use a compiler which is ten times slower and still have shorter build times.
BTW, Git does the right thing WRT timestamps and Makefiles: when it changes a real file, it updates the timestamp to the current time, not the time the version was created. Now that I've used it, I don't understand why tools made the wrong choice for thirty years.
OK, that explains why I've been getting away with assuming they wrap since the Clinton administration. I don't know if anybody ever explained it to me in C terms.
It's *your* responsibility as a C programmer to find out what the rules of the game are; you should accept that responsibility. However...
I always assumed that behavior was baked in at the CPU level, and just percolated up to C. I never felt inclined to do any "bit twiddling" with int or even fixed-width signed integers because on an intuitive level it "felt wrong".
... that's exactly the correct way of thinking (informally) about it. There are so many different representations of signed integers, but only one popular one of unsigned integers.
It seems you could easily distribute the load on multiple machines, each doing a subset of the regex.
There's something hilarious about having to distribute email filtering across several machines.
No; it's tragic that people reach for distributed, or "multi-core", whenever something runs too slowly.
If filtering a mail according to a set of REs takes 15 seconds of CPU time like the OP writes, he's clearly doing something wrong, or hitting some limitation of procmail's design (being unable to amortize work, such as reading and parsing the REs, between mails).
Distributing wasteful work is not the right solution, in particular not if energy efficiency is a major concern like the OP suggests. (And I find it hard to believe that a 15s delay of mail delivery is his main concern!)
Fuck you and your RBLs. RBLs are a draconian solution that do immeasurable damage to those of us who (1) aren't spammers, and (2) choose to run our own mailservers on business-class IPs. [...]
Oh, because someone in the same/24 block sent spam? Really? That's a good reason to block an entire/24 subnet?
That sucks. And more generally, I believe the anti-spam fundamentalists have caused as much damage to the use of reliable mail, as the actual spammers. They are much too willing to accept collateral damage. Sad, when you consider how much effort went into designing (a) guaranteed delivery or (b) guaranteed notification of non-delivery.
For this particular situation: I accepted early on that many misconfigured mail servers "work" like you describe, so I make sure that my ISPs lets me relay via them.
I don't think there's any such thing as "pretty much finished",
There is; software designed according to "do one thing and do it well"... for example the Unix cat(1) command is probably pretty stable by now. Same with fgrep(1).
especially with a piece of software involved in the arms race that is spam vs. filtering.
... but yeah, well, I don't know Spamassassin but I suspect it has broader and more loosely-defined goals.
*Shrug* No. I don't like telling people what to do, and I suspect I'm not good at it. NB this doesn't mean I lack social skills. I can work with people; I just don't want to lead them.
Surely it's not hard to explain? It's how most people feel, after all.
Unless you're a Windows programmer, I'd stick with C, which is infinitely simpler, and provides you freedom to maintain competency in other languages,
Huh? So C++ somehow removes that freedom?
Let me also remind you that while C is simpler than C++, your C source code is more complex than your C++ code -- while doing the same things, using the same APIs and libraries.
Personally, I am tired of implementing linked lists and hash tables for the Nth time and hunting for memory leaks and buffer overflows. Learning C++ was time well spent.
On the other hand, learning to use C is a good idea. It's the lingua franca in the Unix world at least.
many of which have far cooler features than C++ will ever be able to provide.
It is true that you're crippled if all you know is C++. Or C.
Unsurprisingly, neither language is supposed to be the perfect tool for every job.
[C++] Talk about understanding value construction and destruction. And exception safety! Does anyone actually grok it to the degree that one doesn't need to think about it all the time?
I do. It's not hard. Not letting objects be in an invalid state in a context which expects them to be in a *valid* state is something that's important in any code in any language (except maybe functional languages?). C++ is not the problem here but part of the solution.
The why is so that you can take advantage of C++ features. Templates for example are a great way to write very fast code,
Fast code, sure, but the main use for C++ templates is to let you create sane, safe, readable and maintainable code. Or at least remove one of the obstacles for doing so.
Another issue is that some houses are not oriented well to collect sunlight. For example, a house with a single slopes roof that slopes toward the north would be an inefficient place to put solar panels.
That's why they're doing it in Peru, south of the Equator...
Lots of people here saying "Don't use Adobe" and suggesting alternatives. Reality is, for many of us, we deal with complex PDF forms and applications that integrate directly with Adobe Acrobat. In my business
[---]
"Axis of Evil" of insecure software.
That seems like an accurate, believable description of a common situation.
I just wish I'd some time see someone *try to get out* of a lock-in situation like that. Or try to avoid creating more such situations.
It has been well-known for decades that you can end up there, and yet organizations still plunge in, head first, all the time.
(Note that the lock-in isn't just about paying $$$ to the vendor indefinitely. It also means your data is cut off from the rest of the ecosystem; you can't benefit from inventions done elsewhere. No version control for your MS Word documents, and so on.)
I've been in mixed work environments before where everyone just used whatever tools they wanted: Linux, Windows, Mac, Vi, Emacs, etc... I personally used IntelliJ IDEA on Windows because it had code analysis and safe refactoring. My productivity was at least 50x higher than other developers. I was told not to submit changes too fast because the code reviewers couldn't keep up. [...]
I cannot take a claim of 50 times higher productivity seriously.
But, finally real examples! Here's my take, as an "Unix is my IDE" user:
Inefficiencies were everywhere: they took 30 seconds to check out a file from source control using a command-line tool, whereas I could just start typing with a barely noticeable pause on the first character as the IDE does it for me.
Ok, the systems I use mostly don't require a checkout.
Still 30 seconds is hard to explain; I'd do it in 2--3 seconds from Emacs or the shell, if there's no need for a checkout comment. But for systems which do require an explicit checkout, I'd prefer to do it explicitly: plan my work so that I check out roughly the right files with the right comments before I start editing.
They used "diff", I used a GUI 3-way merge tool that syntax highlighted and could ignore whitespaces in a semantically aware way.
That's not even the same task, so I fail to see the point.
Diffing is indeed something you need to do to be efficient.
I like to do simple diffs from Emacs, but often you want something more like "what's my current delta against what's checked out, across the whole project?" and that's better done from the shell.
For (manual) merging, I find GUI merge tools terribly inefficient compared to the "merge and leave both versions of conflicts in the file" strategy of diff3/CVS/Git... I helped introduce that as an alternative at work (where we used to have only GUI 3-way, sequentially over each conflicting file, in a fixed order).
There was one particularly funny moment when some guy walked up to me to ask me to look into a bug in a specific method. He starts off with the usual "now go to the xyz folder, abc subfolder, now somewhere in here there's a..." meanwhile I'm staring at him patiently because I had opened the file before he'd even finished giving me the full method name at the start of his spiel. Global, indexed, semantic-aware, prefix search with jump to file is a feature of IntelliJ IDEA, not Emacs or Vi. He's never even heard of such a thing! Thought it was magic.
If you have coworkers who believe that's magic, you do have a problem.
But you also have a point here: etags/ctags don't play well with "overloaded" names. Fine with C, not so fine with C++ and possibly worse with Java (since you don't have header files which summarize interfaces).
As a C++ guy, I admit that is a weakness of my environment, and it does hurt my productivity somewhat.
Any antivirus solution worth its salt will put a hook in the file open system call to scan each file as it is accessed.
Regardless of the footprint and efficiency of the program, anything that runs each accessed file through an additional filter will incur a significant performance hit.
Therefore, any antivirus solution worth its salt will incur a significant performance hit.
Hm, my experience is the same, but my theory of what's going on is different.
I use Linux at home (no anti-virus) but Windows with encrypted file system and anti-virus (forget which) at work.
Seems to me the problem is I/O load when the anti-virus software decides to rescan everything. There's little CPU load, but everything else slows to a crawl anyway because disk access becomes almost... inaccessible.
A fast CPU or gigabytes of RAM won't help that scenario. Perhaps it's possible to write or tune the anti-virus software to use a lower I/O priority -- but if so I don't understand why they don't do that!
Right, like people are going to know/care the kernel version their smartphone is using. Come on! I've been working and developing software for/on Linux for 15 years and I don't know the version of the kernel I'm running. Hell, I didn't even know kernel versions had names.
They don't; not in any meaningful way anyway. There's a $(NAME) tucked away in the Makefile, and that's what changed from "Unicycling Gorilla" (never heard of it) to "Linux for Workgroups" in commit ad81f0545e. As far as I can tell, this string is not even included in a built kernel. You certainly can't make uname(1) or/proc/sys/kernel/ emit this name.
I said the same thing. Java's success was due to Sun's marketing department more than anything else. I guess the time had come for YALTEAL (yet another language to end all languages).
Yeah. There hadn't been any for a while in the late 1990s. People didn't yet take scripting languages seriously, and trying to use pre-standard C++ (without a standard library!) as if it was Smalltalk had failed some years earlier.
Also, those of us who didn't take Microsoft seriously were impressed that Java came from Sun, the brave defender of the Unix legacy.
Netflix OpenConnect pushes 20GBit+ on a FreeBSD-9 base with nginx and SSDs. Over TCP. To internet connected destinations.
Please re-evaluate your statement.
Ok. My posting was based on experiments with Linux where (at least in 2.6.x kernels) there's a fixed cost for accepting an Ethernet frame, feeding it into the IP stack and to a socket queue. This cost counts as "softirq" time, and cannot be spread across cores. I don't recall exactly which frame size I used, but in my experiments that core became the bottleneck at a few gigabits.
Somewhere between the system you describe and the one I describe, there's a significant difference.
If it's not about heavy customizations and proprietary stacks, then I'm happy to be proven wrong! Even if it turns out that FreeBSD has a better networking subsystem than my beloved Linux.
We're running app stacks at full line rate on 40GbE using today's hardware. A dual-socket sandy bridge server (I.e. HP DL380) has no problem driving that kind of bandwidth. Look up Intel DPDK or 6Windgate if you want to learn a thing or two.
Haven't checked 6Windgate, but Intel DPDK bypasses the IP stack and (as I understand it) pretty much turns the whole machine into an extension of the Intel NICs.
Aren't your machines quite unlike traditional servers? E.g. in O&M and in networking APIs?
But yes, I should not claim the only thing you can use 10Gbit for is to forward it using dedicated hardware.
Ten gigabits per second is 1,250 megabytes per second. High-end consumer SSDs are advertising ~500 MB/sec. A single PCIe 2.0 lane is 500 MB/sec. Then there's your upstream internet connection, which won't be more than 12.5 MB/sec (100 megabits/sec), much less a hundred times that. I guess you could feed 10GbE from DDR3 RAM through a multi-lane PCIe connection, assuming your DMA and bus bridging are fast enough...
More importantly, you can't make an IP stack consume or generate 10Gbit on any hardware I know of, even if the application is e.g. a TCP echo client or server where the payload gets minimal processing. The only use case is forwarding, in dedicated hardware, over 1Gbit links. 10Gbit is router technology, until CPUs are 5--10 times faster than today, i.e. forever.
You had so much room! I learned to program on an Ollevetti Programma 101 in 1971. It was essentially a programmable calculator with 120 possible instruction locations. It used RPN sort of.. and...
There's a documentary about that one; it was on.se television a while ago. Hailed as a precursor to the home computers. But it's spelled "Olivetti".
Today the list of incompatabilities is small and unimportant. I wonder if one will make a really useful difference that would encourage developers choose one or the other; then users would really need to choose. At the moment which you use doesn't really matter.
If that's true, now is the best time to switch. Not when/if the vendor starts squeezing your balls.
Slashdot Mirror
Actually, I think it's partly the embedded people who are pushing for systemd. Which worries me, since many of them don't know or care about Unix.
So, how does making it a binary blob help? The data sources will just produce free form dumps as before, and that's what will end up on the logs. The things that are structured is the time stamp, facility and critical/error/info etc level, and they are easily parseable anyway.
So either the binary blobs don't help at all, or all Unix applications will be forced to adopt some non-Unix structured logging. For my applications, I can say right now I will not do the changes needed to achieve the latter ...
Sounds like plain old etags/ctags. You may have to look at the commit from inside your editor though for that to work, e.g. an Emacs M-x shell.
That, to me, sounds like "I don't trust my build system to do an incremental build". A lot of people don't, and end up spending $$$$ on building provably the same thing over and over again, dozens of times a day ... Stop doing that, and you can use a compiler which is ten times slower and still have shorter build times.
BTW, Git does the right thing WRT timestamps and Makefiles: when it changes a real file, it updates the timestamp to the current time, not the time the version was created. Now that I've used it, I don't understand why tools made the wrong choice for thirty years.
It's *your* responsibility as a C programmer to find out what the rules of the game are; you should accept that responsibility. However ...
It seems you could easily distribute the load on multiple machines, each doing a subset of the regex.
There's something hilarious about having to distribute email filtering across several machines.
No; it's tragic that people reach for distributed, or "multi-core", whenever something runs too slowly. If filtering a mail according to a set of REs takes 15 seconds of CPU time like the OP writes, he's clearly doing something wrong, or hitting some limitation of procmail's design (being unable to amortize work, such as reading and parsing the REs, between mails).
Distributing wasteful work is not the right solution, in particular not if energy efficiency is a major concern like the OP suggests. (And I find it hard to believe that a 15s delay of mail delivery is his main concern!)
What would the database achieve?
Some people believe the solution to any problem involving data is a database ...
Fuck you and your RBLs. RBLs are a draconian solution that do immeasurable damage to those of us who (1) aren't spammers, and (2) choose to run our own mailservers on business-class IPs. [...] Oh, because someone in the same /24 block sent spam? Really? That's a good reason to block an entire /24 subnet?
That sucks. And more generally, I believe the anti-spam fundamentalists have caused as much damage to the use of reliable mail, as the actual spammers. They are much too willing to accept collateral damage. Sad, when you consider how much effort went into designing (a) guaranteed delivery or (b) guaranteed notification of non-delivery.
For this particular situation: I accepted early on that many misconfigured mail servers "work" like you describe, so I make sure that my ISPs lets me relay via them.
I don't think there's any such thing as "pretty much finished",
There is; software designed according to "do one thing and do it well" ... for example the Unix cat(1) command is probably pretty stable by now. Same with fgrep(1).
especially with a piece of software involved in the arms race that is spam vs. filtering.
... but yeah, well, I don't know Spamassassin but I suspect it has broader and more loosely-defined goals.
*Shrug* No. I don't like telling people what to do, and I suspect I'm not good at it. NB this doesn't mean I lack social skills. I can work with people; I just don't want to lead them.
Surely it's not hard to explain? It's how most people feel, after all.
Unless you're a Windows programmer, I'd stick with C, which is infinitely simpler, and provides you freedom to maintain competency in other languages,
Huh? So C++ somehow removes that freedom?
Let me also remind you that while C is simpler than C++, your C source code is more complex than your C++ code -- while doing the same things, using the same APIs and libraries. Personally, I am tired of implementing linked lists and hash tables for the Nth time and hunting for memory leaks and buffer overflows. Learning C++ was time well spent.
On the other hand, learning to use C is a good idea. It's the lingua franca in the Unix world at least.
many of which have far cooler features than C++ will ever be able to provide.
It is true that you're crippled if all you know is C++. Or C. Unsurprisingly, neither language is supposed to be the perfect tool for every job.
[C++] Talk about understanding value construction and destruction. And exception safety! Does anyone actually grok it to the degree that one doesn't need to think about it all the time?
I do. It's not hard. Not letting objects be in an invalid state in a context which expects them to be in a *valid* state is something that's important in any code in any language (except maybe functional languages?). C++ is not the problem here but part of the solution.
The why is so that you can take advantage of C++ features. Templates for example are a great way to write very fast code,
Fast code, sure, but the main use for C++ templates is to let you create sane, safe, readable and maintainable code. Or at least remove one of the obstacles for doing so.
Another issue is that some houses are not oriented well to collect sunlight. For example, a house with a single slopes roof that slopes toward the north would be an inefficient place to put solar panels.
That's why they're doing it in Peru, south of the Equator ...
Lots of people here saying "Don't use Adobe" and suggesting alternatives. Reality is, for many of us, we deal with complex PDF forms and applications that integrate directly with Adobe Acrobat. In my business [---] "Axis of Evil" of insecure software.
That seems like an accurate, believable description of a common situation. I just wish I'd some time see someone *try to get out* of a lock-in situation like that. Or try to avoid creating more such situations. It has been well-known for decades that you can end up there, and yet organizations still plunge in, head first, all the time.
(Note that the lock-in isn't just about paying $$$ to the vendor indefinitely. It also means your data is cut off from the rest of the ecosystem; you can't benefit from inventions done elsewhere. No version control for your MS Word documents, and so on.)
I've been in mixed work environments before where everyone just used whatever tools they wanted: Linux, Windows, Mac, Vi, Emacs, etc... I personally used IntelliJ IDEA on Windows because it had code analysis and safe refactoring. My productivity was at least 50x higher than other developers. I was told not to submit changes too fast because the code reviewers couldn't keep up. [...]
I cannot take a claim of 50 times higher productivity seriously. But, finally real examples! Here's my take, as an "Unix is my IDE" user:
Inefficiencies were everywhere: they took 30 seconds to check out a file from source control using a command-line tool, whereas I could just start typing with a barely noticeable pause on the first character as the IDE does it for me.
Ok, the systems I use mostly don't require a checkout. Still 30 seconds is hard to explain; I'd do it in 2--3 seconds from Emacs or the shell, if there's no need for a checkout comment. But for systems which do require an explicit checkout, I'd prefer to do it explicitly: plan my work so that I check out roughly the right files with the right comments before I start editing.
They used "diff", I used a GUI 3-way merge tool that syntax highlighted and could ignore whitespaces in a semantically aware way.
That's not even the same task, so I fail to see the point. Diffing is indeed something you need to do to be efficient. I like to do simple diffs from Emacs, but often you want something more like "what's my current delta against what's checked out, across the whole project?" and that's better done from the shell.
For (manual) merging, I find GUI merge tools terribly inefficient compared to the "merge and leave both versions of conflicts in the file" strategy of diff3/CVS/Git ... I helped introduce that as an alternative at work (where we used to have only GUI 3-way, sequentially over each conflicting file, in a fixed order).
There was one particularly funny moment when some guy walked up to me to ask me to look into a bug in a specific method. He starts off with the usual "now go to the xyz folder, abc subfolder, now somewhere in here there's a..." meanwhile I'm staring at him patiently because I had opened the file before he'd even finished giving me the full method name at the start of his spiel. Global, indexed, semantic-aware, prefix search with jump to file is a feature of IntelliJ IDEA, not Emacs or Vi. He's never even heard of such a thing! Thought it was magic.
If you have coworkers who believe that's magic, you do have a problem.
But you also have a point here: etags/ctags don't play well with "overloaded" names. Fine with C, not so fine with C++ and possibly worse with Java (since you don't have header files which summarize interfaces). As a C++ guy, I admit that is a weakness of my environment, and it does hurt my productivity somewhat.
Any antivirus solution worth its salt will put a hook in the file open system call to scan each file as it is accessed. Regardless of the footprint and efficiency of the program, anything that runs each accessed file through an additional filter will incur a significant performance hit. Therefore, any antivirus solution worth its salt will incur a significant performance hit.
Hm, my experience is the same, but my theory of what's going on is different.
I use Linux at home (no anti-virus) but Windows with encrypted file system and anti-virus (forget which) at work. Seems to me the problem is I/O load when the anti-virus software decides to rescan everything. There's little CPU load, but everything else slows to a crawl anyway because disk access becomes almost ... inaccessible.
A fast CPU or gigabytes of RAM won't help that scenario. Perhaps it's possible to write or tune the anti-virus software to use a lower I/O priority -- but if so I don't understand why they don't do that!
They don't; not in any meaningful way anyway. There's a $(NAME) tucked away in the Makefile, and that's what changed from "Unicycling Gorilla" (never heard of it) to "Linux for Workgroups" in commit ad81f0545e. As far as I can tell, this string is not even included in a built kernel. You certainly can't make uname(1) or /proc/sys/kernel/ emit this name.
I couldn't agree more, but for secure remote desktop access on a large scale its the best there is.
I still prefer ssh access to a nicely configured Unix box though ...
I said the same thing. Java's success was due to Sun's marketing department more than anything else. I guess the time had come for YALTEAL (yet another language to end all languages).
Yeah. There hadn't been any for a while in the late 1990s. People didn't yet take scripting languages seriously, and trying to use pre-standard C++ (without a standard library!) as if it was Smalltalk had failed some years earlier.
Also, those of us who didn't take Microsoft seriously were impressed that Java came from Sun, the brave defender of the Unix legacy.
Netflix OpenConnect pushes 20GBit+ on a FreeBSD-9 base with nginx and SSDs. Over TCP. To internet connected destinations.
Please re-evaluate your statement.
Ok. My posting was based on experiments with Linux where (at least in 2.6.x kernels) there's a fixed cost for accepting an Ethernet frame, feeding it into the IP stack and to a socket queue. This cost counts as "softirq" time, and cannot be spread across cores. I don't recall exactly which frame size I used, but in my experiments that core became the bottleneck at a few gigabits.
Somewhere between the system you describe and the one I describe, there's a significant difference. If it's not about heavy customizations and proprietary stacks, then I'm happy to be proven wrong! Even if it turns out that FreeBSD has a better networking subsystem than my beloved Linux.
You are so wrong it isn't even funny.
We're running app stacks at full line rate on 40GbE using today's hardware. A dual-socket sandy bridge server (I.e. HP DL380) has no problem driving that kind of bandwidth. Look up Intel DPDK or 6Windgate if you want to learn a thing or two.
Haven't checked 6Windgate, but Intel DPDK bypasses the IP stack and (as I understand it) pretty much turns the whole machine into an extension of the Intel NICs. Aren't your machines quite unlike traditional servers? E.g. in O&M and in networking APIs? But yes, I should not claim the only thing you can use 10Gbit for is to forward it using dedicated hardware.
Ten gigabits per second is 1,250 megabytes per second. High-end consumer SSDs are advertising ~500 MB/sec. A single PCIe 2.0 lane is 500 MB/sec. Then there's your upstream internet connection, which won't be more than 12.5 MB/sec (100 megabits/sec), much less a hundred times that. I guess you could feed 10GbE from DDR3 RAM through a multi-lane PCIe connection, assuming your DMA and bus bridging are fast enough...
More importantly, you can't make an IP stack consume or generate 10Gbit on any hardware I know of, even if the application is e.g. a TCP echo client or server where the payload gets minimal processing. The only use case is forwarding, in dedicated hardware, over 1Gbit links. 10Gbit is router technology, until CPUs are 5--10 times faster than today, i.e. forever.
You had so much room! I learned to program on an Ollevetti Programma 101 in 1971. It was essentially a programmable calculator with 120 possible instruction locations. It used RPN sort of.. and ...
There's a documentary about that one; it was on .se television a while ago. Hailed as a precursor to the home computers. But it's spelled "Olivetti".
Today the list of incompatabilities is small and unimportant. I wonder if one will make a really useful difference that would encourage developers choose one or the other; then users would really need to choose. At the moment which you use doesn't really matter.
If that's true, now is the best time to switch. Not when/if the vendor starts squeezing your balls.