> When you have practices like that going on, you're going to have a LOT of rotten apples in the Indian dev barrel.
The Indian QA and systems personnel are even more fun to work with. I mastered a long-term very effective practice with low-bid off-shore contractors. I _train_ them, ideally in open source tools, to do a better job. They graduate to better work for their company or other companies, I make sure that both their boss and _my_ project supervisor knows I trained them, and after 3 or four rounds the supervisor realizes what's going on and hires the people _I_ help interview and encourage in their careers to do the task without the excess turnover. And in the meantime, we get much better work from the low cost developers or QA personnel or system admins.
It's very expensive in my time, but the training helps me refine _my_ tools and skills, and gets better work done for my employer or their business partner. At this point, I have quite a few mid-level and even senior overseas developers I can call on for favors, international software support, or just networking to place people in their countries. I suggest it's how foreign consulting works at its best.
It raises the risk of your best talent becoming aware of the cuts and leaving, with only the dead wood remaining. A significant amount of my salary comes from helping clean up after that when the people who really understand the technology leave.
The price between a vendor and their contractors is often a trade secret. The Lyft fares paid to the driver, in this case, are not published to the customer. Those prices are published directly to the Lyft driver.
You seem quite confident. Theft of trade secrets, even through an unwitting proxy to those trade secrets, is still theft. Much would depend on the details of the contract with Uber, and much would depend on whether the software committed acts which the Uber drivers had _not_ agreed to in their contracts. The drivers working for Lyft might not even be empowered, by their Lyft contract, to share that information with Uber, in which case they could not agree to share that data.
I'm afraid that I've encountered a few engineers who refuse to acknowledge the distinction between UNIX operating systems, which follow certain detailed standards documented in the "Single UNIX Standard" at https://www2.opengroup.org/ogs... and other operating systems whose kernels, and whose core libraries, have critical distinctions. MacOS, for example, is. Linux is not, as documented at https://www.iso.org/standard/3... . Solaris was, and SCO OpenServer was, as was AT&T SysV.
Following a standard in every detail can be difficult, confusing, and expensive to verify. This is partly why genuine UNIX operating systems have fallen out of favor in many environments.
I must admit that "Aspirer syndrome" is funnier. Given the behavior of some of my technical acquaintances who claim that their self diagnosis of Aspbeerger's disease somehow makes them more intelligent, I might call it a better label than Aspberger's. But not in a workplace sensitive to "trigger words".
> In my experience what makes developers unhappy is having to write documentation, perform testing and fixing bugs.
I suspect those are factors that make _poor_ developers unhappy. For good developers, and admins, many of us find writing good documentation to be an invaluable tool that helps people actually use our work. For those of us who've come back to a project after 3, 5, or even 15 years, it's invaluable. For me, the act of documenting helps me think about why I'm making certain choices, and provide a trail for others to avoid the same pitfalls.
cakkegw also commented:
> No, what makes me sad is asking a colleague for the script he wrote that automates some task, and discovering that there's not a single line of comments in it
What's making me sad lately is asking a project member for the tools they wrote that automate some task, finally getting them to put the tools in source control, and discovering that not only is there no documentation, the tools do not report errors, they've not been working correctly, and the tools already exist in much more stable and documented form in some open source project. It's coupled with the same engineer or group handwaving their way around the project, refusing to use stable upstream tools and instead using the latest unstable and untested tools that corrupt the original data without notice.
I had the opportunity several years ago to review some of the code used for a major genetic analysis project. I was horrified, but unsurprised, at the lack of error checking. I was also horrified at the internal documentation that was in direct conflict with what the code actually did. I'm afraid the details are under NDA, but it was not cheap to clean it up and re-run all the analysis. I dread to think how much research money and effort the bad data analysis wsted.
> WTF... really? A tricorder is "just" about do-able with the tech we have now, its a first step,
Considering that most of the physics is not feasible, I suspect you're quite confused about "what is doable". Difficult if not impossible factors include:
1) Enormous stored information about numerous engineering and medical subjects to correctly identify the measured results. 2) Measurement of physical structures and energy throughout the electromagnetic spectrum, probing of remote mechanical, organic, and chemical systems without applying significant energy that would distort the system and without any destructive analysis. 3) Isolated measurement and mapping of local weather and environments internal sensors, without communicating with a larger network of devices that might provide more interpretable data. 4) The ability to differentiate biologically and without physical tissue sampling between alien races that are, nonetheless, mostly the same species since they can successfully breed.
The list goes on. One of the critical missing factors is the ability to make detailed chemical analysis without taking a sample. _Nothing_ today can do that, and there is no sign of any technology in modern research that can. Even spectral analysis without exposing the subject to a well defined light source such as a laser is limited by the overlap of the responses of similar complex spectral responses that obscure spectral response without purified samples.
> The primary antisocial aspect of smoking is the risk of cancer from second hand smoke.
The secondary aspects are also problematic. I've acquaintances with asthma, and at my age, acquaintances with emphysema and with chronic obstructive pulmonary disease. Many of those cases were due to smoking, but fewer and fewer as time progresses and smoking has fallen out of favor. I still meet some, as I age and run into other people as old or older than myself, and I've been able to see their lives as easier without smoke in the workplace or on the streets.
It's a dangerous and addictive habit that does, indeed, produce mild stimulation. People who are nervous or depressed have long reported positive, self-medicating effects with it.
It's irrelevant to the management who are collecting salaries and collecting options. The options may not be worth a lot to rank and file employees, but when the company is finally bankrupted or sold off, those can still turn a tidy profit for managers. I saw this done by various manipulative means in the dotcom era.
> Pretty sure the driver can take any route they (or the passenger) like. Which is probably why Uber is padding the up front cost.
As best I can tell, Uber and Lyft and other services monitor the routes _actually_ taken by the drivers quite closely. It's part of how they aggregate data about shortcuts, blocked roads, and other useful mapping informaiton.
I've not seen this with Lyft, which I've used extensively for the last few years. Can other Slashdot readers confirm that they're seeing the route they're being driven does not match the route they were shown when they contacted Uber?
For small scale, "one time use filters", you can simply distill the water by boiling it. It's the industrial scale "water our crops", "provide drinking water for a community", or "provide water for industry" that require large scale systems and for which the maintenance cost and energy cost of known, stable techniques like evaporation make it impractical.
It is a difficulty, even at leal speeds, if you have an awkward or delicate load. I've occasionally driven quite expensive equipment through back alleys and parking lots where speed bumps risked breaking my company's, or our client's hardware..
They download the disks, once, as needed. I've downloaded cracked versions of games I purchased, in order to play them with an ISO image rather than a hardware locked CD or DVD on a system that didn't _have_ a DVD drive. I've similarly downloaded DVD images of movies I bought, in order to play them in the country I happened to be in at the moment.
You can't safely relicense without negotiating the new license with the copyright holders.
The "advertising clause" embedded in the existing OpenSSL license does present an awkward confusion for LibreSSL. I'm curious to see if this is partly an attempt to clarify the licensing for LibreSSL and for commercial forks, for whom the advertising clause can be difficult to explain to clients.
It's why the FSF is so very careful that the GPL grants licenses to existing users, and are transitive so that changes are _also_ under GPL and free for publication and modificaiton. It's also why various "you must advertise our name on this software" or "you may not make any changes to this software" have repeatedly proven confusing and dangerous to use.
It was a dual license. One of the licenses was unique to OpenSSL. LibreSSL is no better in this sense, and seems to have the exact OpenSSL license, as listed here:
The Apache license has been more portable and more acceptable to many developers and software publishers. It will be very interesting to see how this plays out.
The risk of "have its value automatically replaced with null or empty or undefined" for on-the-fly variables may be addressed in Erlang. Are you saying that Erlang avoids the risk of _overwriting_ desired data with a separate write to the variable with the same name by a different procedure added by a different developer? Unless all functions are local, or all scoping is local, then I find that quite difficult to believe. It's also quite expensive in system resources when function calls occur.
While true that China is too large a trading partner to ignore, trade with them has more legal and financial levers to apply. Tariffs matter a great deal to trade with China. So do exports from the US, especially aircraft, electrical equipment, food, and a number of other US exports.
It has suffered from a problem common to various object oriented projects: by refusing to acknowledge the existence of lower level structures, such as the very real storage hardware and real network connections necessary to propagate the data among the nodes for effective access, the result is that it didn't scale. Backup of results from well-delineated processing steps, which is critical for debugging or re-running new versions of particular processing steps, wound up being quite slow, quite expensive, and was often ignored. The result often became a demand for complete snapshotting of the _entire_ system before scheduled processing, which does _not_ scale well. And the critical management nodes themselves increased in fragility as the system scaled.
> Map Reduce does have the advantage of in the ability to resume (rather than restart) queries on failure.
Only for failures of the particular query. From my experience, very few programmers elected to verify the results of any query. And if the query failed, it should be _reported_ as failed and re-run as needed. The possibility of a failure of the MapReduce[sic] system itself was seen as involving a different layer of abstraction. I'm afraid that some, if not most, Java programmers have been taught _not_ to acknowledge or to deal with errors from lower layers. Errors for individual operations grew exponentially in frequency as the size of a cluster grew. From a recent project, anything more than approximately 10 nodes with more than 20 TB of overall disk space failed so often that it was unusable.
Ad-hoc queries are important to be able to handle. Many that I've seen in fieldwork are so badly structured that spending the engineering time on a database programmer who can help optimize them is much more cost effective. Such an engineer can even work on the underlying RDBMS structures if needed, at far greater cost/benefit than trying to maintain a MapReduce system.
> MapReduce is actually great for teaching people about parallel processing! I
And about how _not_ to do it. The underlying expense and architecture mistakes "scalability" for actual throughput in processing. It's proven extremely unstable in tasks larger than a small proof of concept, and any task I've encountered in which the actual data to be processed has to be successfully, processed, and verified within a specified deadline.
Slashdot Mirror
> When you have practices like that going on, you're going to have a LOT of rotten apples in the Indian dev barrel.
The Indian QA and systems personnel are even more fun to work with. I mastered a long-term very effective practice with low-bid off-shore contractors. I _train_ them, ideally in open source tools, to do a better job. They graduate to better work for their company or other companies, I make sure that both their boss and _my_ project supervisor knows I trained them, and after 3 or four rounds the supervisor realizes what's going on and hires the people _I_ help interview and encourage in their careers to do the task without the excess turnover. And in the meantime, we get much better work from the low cost developers or QA personnel or system admins.
It's very expensive in my time, but the training helps me refine _my_ tools and skills, and gets better work done for my employer or their business partner. At this point, I have quite a few mid-level and even senior overseas developers I can call on for favors, international software support, or just networking to place people in their countries. I suggest it's how foreign consulting works at its best.
It raises the risk of your best talent becoming aware of the cuts and leaving, with only the dead wood remaining. A significant amount of my salary comes from helping clean up after that when the people who really understand the technology leave.
The price between a vendor and their contractors is often a trade secret. The Lyft fares paid to the driver, in this case, are not published to the customer. Those prices are published directly to the Lyft driver.
> It's not. And as a Lyft driver,
You seem quite confident. Theft of trade secrets, even through an unwitting proxy to those trade secrets, is still theft. Much would depend on the details of the contract with Uber, and much would depend on whether the software committed acts which the Uber drivers had _not_ agreed to in their contracts. The drivers working for Lyft might not even be empowered, by their Lyft contract, to share that information with Uber, in which case they could not agree to share that data.
I'm afraid that I've encountered a few engineers who refuse to acknowledge the distinction between UNIX operating systems, which follow certain detailed standards documented in the "Single UNIX Standard" at https://www2.opengroup.org/ogs... and other operating systems whose kernels, and whose core libraries, have critical distinctions. MacOS, for example, is. Linux is not, as documented at https://www.iso.org/standard/3... . Solaris was, and SCO OpenServer was, as was AT&T SysV.
Following a standard in every detail can be difficult, confusing, and expensive to verify. This is partly why genuine UNIX operating systems have fallen out of favor in many environments.
I must admit that "Aspirer syndrome" is funnier. Given the behavior of some of my technical acquaintances who claim that their self diagnosis of Aspbeerger's disease somehow makes them more intelligent, I might call it a better label than Aspberger's. But not in a workplace sensitive to "trigger words".
The word is trademarked, and the word UNIX is capitalized. And no, "UNIX" is not "Linux".
> Software upgrades often come with changes to the UI which often require that the user relearn how to use their software
And the old software and interfaces will go on needing to be supported. There's an amusing old XKCD cartoon about this.
https://xkcd.com/1172/
> In my experience what makes developers unhappy is having to write documentation, perform testing and fixing bugs.
I suspect those are factors that make _poor_ developers unhappy. For good developers, and admins, many of us find writing good documentation to be an invaluable tool that helps people actually use our work. For those of us who've come back to a project after 3, 5, or even 15 years, it's invaluable. For me, the act of documenting helps me think about why I'm making certain choices, and provide a trail for others to avoid the same pitfalls.
cakkegw also commented:
> No, what makes me sad is asking a colleague for the script he wrote that automates some task, and discovering that there's not a single line of comments in it
What's making me sad lately is asking a project member for the tools they wrote that automate some task, finally getting them to put the tools in source control, and discovering that not only is there no documentation, the tools do not report errors, they've not been working correctly, and the tools already exist in much more stable and documented form in some open source project. It's coupled with the same engineer or group handwaving their way around the project, refusing to use stable upstream tools and instead using the latest unstable and untested tools that corrupt the original data without notice.
I had the opportunity several years ago to review some of the code used for a major genetic analysis project. I was horrified, but unsurprised, at the lack of error checking. I was also horrified at the internal documentation that was in direct conflict with what the code actually did. I'm afraid the details are under NDA, but it was not cheap to clean it up and re-run all the analysis. I dread to think how much research money and effort the bad data analysis wsted.
> WTF... really? A tricorder is "just" about do-able with the tech we have now, its a first step,
Considering that most of the physics is not feasible, I suspect you're quite confused about "what is doable". Difficult if not impossible factors include:
1) Enormous stored information about numerous engineering and medical subjects to correctly identify the measured results.
2) Measurement of physical structures and energy throughout the electromagnetic spectrum, probing of remote mechanical, organic, and chemical systems without applying significant energy that would distort the system and without any destructive analysis.
3) Isolated measurement and mapping of local weather and environments internal sensors, without communicating with a larger network of devices that might provide more interpretable data.
4) The ability to differentiate biologically and without physical tissue sampling between alien races that are, nonetheless, mostly the same species since they can successfully breed.
The list goes on. One of the critical missing factors is the ability to make detailed chemical analysis without taking a sample. _Nothing_ today can do that, and there is no sign of any technology in modern research that can. Even spectral analysis without exposing the subject to a well defined light source such as a laser is limited by the overlap of the responses of similar complex spectral responses that obscure spectral response without purified samples.
> The primary antisocial aspect of smoking is the risk of cancer from second hand smoke.
The secondary aspects are also problematic. I've acquaintances with asthma, and at my age, acquaintances with emphysema and with chronic obstructive pulmonary disease. Many of those cases were due to smoking, but fewer and fewer as time progresses and smoking has fallen out of favor. I still meet some, as I age and run into other people as old or older than myself, and I've been able to see their lives as easier without smoke in the workplace or on the streets.
It's a dangerous and addictive habit that does, indeed, produce mild stimulation. People who are nervous or depressed have long reported positive, self-medicating effects with it.
> Uber is losing money. Hand over fist.
It's irrelevant to the management who are collecting salaries and collecting options. The options may not be worth a lot to rank and file employees, but when the company is finally bankrupted or sold off, those can still turn a tidy profit for managers. I saw this done by various manipulative means in the dotcom era.
> Pretty sure the driver can take any route they (or the passenger) like. Which is probably why Uber is padding the up front cost.
As best I can tell, Uber and Lyft and other services monitor the routes _actually_ taken by the drivers quite closely. It's part of how they aggregate data about shortcuts, blocked roads, and other useful mapping informaiton.
I've not seen this with Lyft, which I've used extensively for the last few years. Can other Slashdot readers confirm that they're seeing the route they're being driven does not match the route they were shown when they contacted Uber?
For small scale, "one time use filters", you can simply distill the water by boiling it. It's the industrial scale "water our crops", "provide drinking water for a community", or "provide water for industry" that require large scale systems and for which the maintenance cost and energy cost of known, stable techniques like evaporation make it impractical.
It is a difficulty, even at leal speeds, if you have an awkward or delicate load. I've occasionally driven quite expensive equipment through back alleys and parking lots where speed bumps risked breaking my company's, or our client's hardware..
They download the disks, once, as needed. I've downloaded cracked versions of games I purchased, in order to play them with an ISO image rather than a hardware locked CD or DVD on a system that didn't _have_ a DVD drive. I've similarly downloaded DVD images of movies I bought, in order to play them in the country I happened to be in at the moment.
You can't safely relicense without negotiating the new license with the copyright holders.
The "advertising clause" embedded in the existing OpenSSL license does present an awkward confusion for LibreSSL. I'm curious to see if this is partly an attempt to clarify the licensing for LibreSSL and for commercial forks, for whom the advertising clause can be difficult to explain to clients.
It's why the FSF is so very careful that the GPL grants licenses to existing users, and are transitive so that changes are _also_ under GPL and free for publication and modificaiton. It's also why various "you must advertise our name on this software" or "you may not make any changes to this software" have repeatedly proven confusing and dangerous to use.
> OpenSSL can only be improved by rewriting.
Given the lack of portability demonstrated by LibreSSL, this is not as certain as you may think.
It was a dual license. One of the licenses was unique to OpenSSL. LibreSSL is no better in this sense, and seems to have the exact OpenSSL license, as listed here:
* https://github.com/libressl/li...
The Apache license has been more portable and more acceptable to many developers and software publishers. It will be very interesting to see how this plays out.
The risk of "have its value automatically replaced with null or empty or undefined" for on-the-fly variables may be addressed in Erlang. Are you saying that Erlang avoids the risk of _overwriting_ desired data with a separate write to the variable with the same name by a different procedure added by a different developer? Unless all functions are local, or all scoping is local, then I find that quite difficult to believe. It's also quite expensive in system resources when function calls occur.
While true that China is too large a trading partner to ignore, trade with them has more legal and financial levers to apply. Tariffs matter a great deal to trade with China. So do exports from the US, especially aircraft, electrical equipment, food, and a number of other US exports.
> Can you elaborate on some reasons?
It has suffered from a problem common to various object oriented projects: by refusing to acknowledge the existence of lower level structures, such as the very real storage hardware and real network connections necessary to propagate the data among the nodes for effective access, the result is that it didn't scale. Backup of results from well-delineated processing steps, which is critical for debugging or re-running new versions of particular processing steps, wound up being quite slow, quite expensive, and was often ignored. The result often became a demand for complete snapshotting of the _entire_ system before scheduled processing, which does _not_ scale well. And the critical management nodes themselves increased in fragility as the system scaled.
> Map Reduce does have the advantage of in the ability to resume (rather than restart) queries on failure.
Only for failures of the particular query. From my experience, very few programmers elected to verify the results of any query. And if the query failed, it should be _reported_ as failed and re-run as needed. The possibility of a failure of the MapReduce[sic] system itself was seen as involving a different layer of abstraction. I'm afraid that some, if not most, Java programmers have been taught _not_ to acknowledge or to deal with errors from lower layers. Errors for individual operations grew exponentially in frequency as the size of a cluster grew. From a recent project, anything more than approximately 10 nodes with more than 20 TB of overall disk space failed so often that it was unusable.
Ad-hoc queries are important to be able to handle. Many that I've seen in fieldwork are so badly structured that spending the engineering time on a database programmer who can help optimize them is much more cost effective. Such an engineer can even work on the underlying RDBMS structures if needed, at far greater cost/benefit than trying to maintain a MapReduce system.
> MapReduce is actually great for teaching people about parallel processing! I
And about how _not_ to do it. The underlying expense and architecture mistakes "scalability" for actual throughput in processing. It's proven extremely unstable in tasks larger than a small proof of concept, and any task I've encountered in which the actual data to be processed has to be successfully, processed, and verified within a specified deadline.