Uber and Lyft are in no way representative of free market principles.
In a free market, I need a ride somewhere, I put out a bid for what I'm willing to pay for that ride. If a driver likes my offer, they can accept it or counter. That's free market ride sharing.
Uber is simply a market for rides regulated by Uber, just as taxi services are markets for rides regulated by governments. You, as the rider, are completely at their mercy for setting your fare. Drivers are also completely at Uber's mercy for setting their rate. That's the opposite of a free market.
Even if you look at it from the service perspective of allowing ride sharing companies to create competing ride markets, Uber fails. Uber is heavily subsidized by its investors and foreign governments (Saudi Arabia's $3.5B investment, for example) and has never had to compete on costs. Again, something antithetical to free market principles.
Of course, just like I had Pets.com deliver 50lb bags of dog food for free in 1999 and used Instacart until they jacked up their rates, I'm happy to spend investor's money on cheap rides. No point in missing out on the party while it's happening.
When Uber and Lyft stomped out of Austin like whiney, spoiled brats, the free market stepped in a started creating alternatives. One of them is a non-profit:
"Earlier this month the site compared this year's drunk driving arrests to last years -- and discovered that in the three weeks since Uber and Lyft left Austin, 7.5% more people have been arrested for drunk driving."
Keep in mind that that was a 6 week sample in absolute terms (not relative to population growth or corrected for any other factors, like more aggressive policing, festivals/events that could have spiked rates, weather, etc - it was just raw year-over-year numbers). It's bad statistics. It's been a bit depressing to watch so many techies (including many of my data science friends who should know better) blindly believe Uber/Lyft's messaging.
I live in Austin and I'm really sick of the Uber/Lyft propaganda machines. All they're doing is spending their VC money on lobbying and lawyers to mold communities in their image rather than trying to develop a service that actually works with the communities they serve (seriously: they spent $9MM trying to influence a local election. What a waste of some investor's money.) Uber is just a grand VC experiment in seeing how they can run illegal businesses and force laws to change for them. They tried it in health (23andMe, Therenos) and found the FDA to be a formidable opponent and instead went after an unpopular industry (taxis) to develop their playbook. Once they work out the playbook with taxis, they'll go after other regulated industries.
Remember, Uber and Lyft were not forced out of Austin. They simply left because they didn't want to play by the rules. They could have stayed. What's exciting is that the market is working and a whole new crop of TNCs are evolving in Austin that are willing to work with the community rather than against it.
And don't get me wrong, I love the idea of TNCs. They're great services, they just need to play by the same rules as everyone else and when those rules don't seem to be right, work with the community to find ones that do (compromise is part of that). Right now, Uber and Lyft are just acting like that spoiled rich kid you knew growing up who was never held accountable for his actions.
Interesting what you did there, calling the $13.00 after expenses a "profit". What's left out in the expenses is the salary for the contractor. That $13.00 is their take home pay after the expenses of running their car. So, if you have zero living expenses and don't eat, then sure, call it profit. But since Uber drivers are humans, they actually need food and shelter. Some of us also think that all humans should have a decent standard of living and have a decent work/life balance, not just those of us that can make six figures surfing the web all day and occasionally banging out a few lines of code.
$13.00 take home pay equates to roughly $26k/year (using the standard 2000 hour work year that every software person I know uses to compute their "salary" based on their consulting rate). The poverty line in the US is roughly $23k.
tl;dr: the $13.00 is not profit, it's salary; $13/hr won't even let you save and the US deems that salary the bare minimum to just scrape by. Working more destroys the work/life balance.
"Apple declined to comment on why it didn’t follow its usual procedure."
Someone did ask, Apple didn't say anything.
Which is Apple's usual procedure (not responding). Heck, even within Apple engineers aren't allowed to share details like this outside of their immediate team.
But, as many other posts have pointed out, the source code for most of the kernel is already open source and iOS was unencrypted until iOS 8. Not really much to see here...
(on a side note, what's up with/. suddenly becoming just a string of "gotcha" stories about software bugs and corporate mistakes?)
All of them? When I contract, I tell my prospective customers my rate and they can either work with me, offer a different rate, or look for a different contractor. Uber drivers don't have this flexibility.
If you remember the dot com bust, there were a few precipitating events that got everyone looking closer at sky-high valuations. Enron is probably the most important of those. While Enron wasn't a dot com, they used some very creative accounting practices to book revenue and inflate their value (innovative, disruptive, new economy, and all that). Their crash helped highlight the funny math going on at internet companies and helped get investors and regulators asking the hard questions.
The current bubble has a few possible candidates for an Enron-style scandal. I've thought that Theranos might be it - they fit the broader narrative of youthful founders disrupting stodgy industries and minting new billionaires. Then there's Uber, but they have enough investor money in the bank to hide any structural issues with their business model for years. Palantir is another that may help burst the bubble as they learn that the outrageous consulting rates and blind faith in their methods they received from the military are difficult to replicate in the business world when you have some level of accountability to shareholders and customers. They have less cash than Uber to mask their situation much longer.
But, maybe it will be just like before: good old math that no longer adds up. At some point, all the SaaS companies using the clouds will run out of credits and goodwill from the providers and be asked to pay real rates for the services (just in case you don't know: almost no SaaS company actually pays for their hosting on the major cloud providers for the first year or so, and even then they pay deeply discounted rates. And if you're at a SaaS paying full rates to Amazon or similar, you need to call your rep - your competition is paying less than you. The cloud providers do this in hopes that strong businesses will emerge that they can eventually reap profits from - Salesforce is the classic example). I'm guessing* that all the major cloud providers are using some form of funny math to hide this.
So, Oracle's probably not going to suffer the fate of Enron. But, just like in the last bubble, "clever" accounting may be what finally pops it.
-Chris
*ok, I know from direct experience how at least two of them are doing it, and yes, they're doing it
Of course existing infrastructure is bad for hydrogen, but upgrading existing infrastructure is part of the benefit for the hydrogen crowd. While the physical elements of our current infrastructure definitely won't support hydrogen, the business infrastructure is already in place to match the existing fuel distribution model. A one-time cap-ex investment to swap out fossil fuel infrastructure components with components that can support hydrogen is all that is needed to maintain the existing business model. Sure, it won't be cheap, but it will likely be a supported by tax incentives (create local jobs to do the retrofit, write off retrofit) and it provides an opportunity for the oil service industry to learn hydrogen infrastructure by developing it on the taxpayer's dime.
Don't think about this like a financial engineer, not a civil engineer. It doesn't matter what makes the most sense from a technical perspective, what matters is not disrupting cash flow for entrenched industries. I didn't really appreciate this argument until I started running a company. But after spending the last four years around finance people, I have a new appreciation about how they (and by extension, most businesses) view the world. They optimize around profits, not technology.
I remember talking with my grandfather years ago about the future of energy for cars. He's a EE who ran a telecom infrastructure company for years and always saw things from the infrastructure perspective. Whatever was least disruptive to the energy ecosystem as a whole was going to win. Given the entrenched players at every stage in the distribution chain, hydrogen made the most sense. Each industry segment would profit greatly from upgrading their infrastructure to support hydrogen while not having to abandon their place in the process.
Electric cars upend multiple industries - from oil services all the way to convenience stores. Change will be fought tooth-and-nail. I just hope Elon doesn't run out of cash before he's had a chance to force the issue on electric cars.
Your points are why I think we need to have a broader discussion about this.
Historically, "open" specifications were industry designed "APIs" that enabled interoperation between multiple implementations. However, implementing them required a license and/or certification from the organization that maintained the spec. The specs were published and implementations were encouraged, but only under specific terms. Of course, the availability of the specs did wonders for technology and competition. Pretty much everything we rely on today from networking, to hardware, to graphics, to sound processing evolved this way.
As we transitioned more to software APIs, certification requirements became less important (a bad API implementation isn't going to cause a fire). APIs also tended to be more tightly coupled with a single implementation. Competition usually evolved in the form of a new implementation/API (e.g., QT vs. GTK vs. wxWidgets to pick a somewhat recent example) rather than something that was API compatible. In fact, most APIs out there will only ever have one implementation.
Developing a spec or API that's truly general purpose and usable for interoperability is time consuming and costly. The old approach accounted for this by designing them through industry funded organizations with all parties going in knowing they would benefit. Software APIs, by and large, are developed by one person or a small group on their own dime. If their API is generally useful and manages to succinctly capture a problem domain in a way that would benefit from multiple implementations, they should be compensated for that effort.
At a higher level, society doesn't have any more right to the API than it did before it was developed. The simple fact that it does benefit society proves that the design was valuable. Again, the developer should be compensated and society should gain (we need to stop thinking these two things are mutually exclusive). This also is the general basis for our intellectual property laws - creators are granted a term of exclusivity in exchange for sharing their work with the world.
I understand the desire to have instant, free access to every great idea. But, as a creator, I also see it from the other side.
The musical notation is the character set you use to communicate the melody. Saying notation is like an API is like saying ASCII or UTF-8 is an API.
I agree that a good part of the software industry will be impacted by allowing APIs to be copyrighted and it may be detrimental in many cases. But, as this case is demonstrating, it's a conversation we need to have as an industry. We need to decide if creators have the right to protect their intellectual property and, if so, under what provisions they can that provide the best balance between creator rights and user rights.
"And why do you think they're going through the effort to keep the prices low?"
To wipe out the competition and then raise prices when there's no more competition. Pretty much what every good capitalist wants to do.
The only competition Uber and Lyft they have at the low end of price spectrum is each other. Of course, they need each other in the same way Intel needs AMD - to demonstrate to regulators that they aren't a monopoly. The competition they need to wipe out is taxis and other TNCs (transportation network company) that pay fair wages and follow the laws. Wiping out taxis is pretty easy, since there have been structural issues with the taxi business for decades. Wiping out the other TNCs is going to be a little harder since the new services are demonstrating that you can run a TNC that follows the law and pays its drivers a reasonable wage.
As Austin will likely demonstrate, the race to the bottom in compliance and wages being run by Uber and Lyft is probably not the real race to provide alternatives to taxis. Business that respect their drivers, communities, and passengers will emerge as the winners here.
No, they're cheap because they're burning through piles of cash from their investors and a (limited, but still large) pool of drivers willing to work a few months before they realize they got a bum deal. Both will run dry, at which point the TNC experiment will end.
For a really good discussion on the economics from the driver's side, check out any of the recent reddit threads in Austin discussing Uber and Lyft's decision to cut off 10k drivers and split town. Here's one to get you started: https://www.reddit.com/r/Austi...
Ok, I'm going to take a slightly unpopular stance here and suggest that APIs probably should be copyrightable.
Ignoring all the legal issues, my rational is simple: An API spec represents the output of the intellectual effort of the architect far better than any implementation code. Designing a good API is difficult. Doing so requires finding exactly the right abstractions to allow users to use your API to perform complex operations in a simple, straightforward manner. The design process often involves several iterations of implementation to refine the API - not only implementing the functionality, but writing software that uses to to make sure it meets its goals.
The book title/chapter title argument is often used to show why APIs shouldn't be copyrighted. That's a poor analogy. Many books don't bother with chapter titles, so they're clearly not essential to the interpretation of the material. When present, they usually can't be used to quickly summarize a book. A well designed API will clearly and concisely present to you everything the underlying library can do. In fact, you should never care about the implementation of the library. If you ignored the text of a book, you wouldn't really be reading it.
If we're going to look to artistic pursuits for analogies, I'll suggest music is a better one. Melodies and lyrics are primarily what's copyrightable in music. Chord changes and musical embellishments are not. Arrangements are copyrightable when written down. Specific performances are also copyrightable (which is why samples must be cleared for use in other songs). Melodies and lyrics are akin to an API - the instantly let you identify the song/library and are the primary way most people remember it. For example, I can play "Yesterday" on a piano, guitar, speak-and-spell, and it's still a Beatles song. I still owe the Beatles royalties for using their lyrics and melody, regardless of how I arrange and perform it.
Now, if we allow APIs to be copyrighted, we gain a lot of flexibility. Most importantly, the copyright holder can release the API under a free and open license if they want. The designer can say: here's my work, feel free to do with it what you want. Or, they can lock it down and restrict what can be done with it.
For better or worse, Sun wanted the best of both worlds with Java. They implied that it was free and open, but never actually released the APIs under a specific free and open license. In the music world, the "Happy Birthday" saga is similar. The melody and lyrics were thought to be under copyright and Warner collected a few million a year from artists for performing it and using it in their works. Just like the core Java APIs, everyone knows "Happy Birthday" and most people used it casually without paying royalties (yes, I realize not everyone knows Java, but most readers of/. do). With the song, it turned out an earlier version that wasn't under copyright was found, which invalided Warner's claims. Unfortunately, that's unlikely to happen with Java.
tl;dr: APIs are the creative output of the design process, just like melodies and lyrics are in music. They probably should be copyrightable.
One person's trash is another's feast. Most of the music on the radio is actually quite good, if you're a fan of music and not just a fan of one particular genre. Pop music, for all its commercial faults, is popular for a reason. People like it.
Sure, classical and folk are good, too. So is jazz, rock, EDM, noise (yeah, it's a genre), and just about every other style people have come up with.
I challenge you to listen to some EDM and compare it to your favorite classical pieces. While we have had 300+ years to study classical music to death, the overall structure of the music is pretty much the same as EDM: invent a theme/hook, make some variations on it, connect the variations together for dramatic effect, embellish it all using the underlying implied chordal structure by overusing arpeggios;).
Folk and Pop basically have the same relationship. Both tend to have rigid rules around song structure (ABAB,ABCAB, etc), use simple chord changes (almost always some mix of I, IV, V in both genres), and have lyrics that resonate with the listener base. Interestingly, they're also controlled with an iron fist by the powers in the genres - just try developing a new folk song without approval of the keepers of the Great American Songbook.;) (I play in a country/folk band, the powers-that-be are almost as annoying as those from the jazz world, where I've also spent a lot of time)
The meta point being: Across genres, music is more similar the different. I encourage you to go on a listening bender across your local FM stations and seed a few Pandora stations with random things.
Huh? H1-Bs aren't citizens and can't vote. It's only when you get citizenship that you can vote. The number of new citizens nationally is only in the mid hundreds of thousands each year, so not enough to impact elections. (source: https://www.uscis.gov/archive/...)
Liberal Democrats (at least all that I know, and I live in Austin, so that's pretty much everyone I know) tend to support immigration for humanitarian, not selfish reasons.
1) On a green light? Please show me the citation to Texas law that says that only one car is allowed in an intersection on a green light (yes, I'm calling BS on your claim and putting the burden of proof on you). I'm pretty sure that's the rule for intersections controlled by stop _signs_, but it's not the rule for stop _lights_.
2) The Google car had already cleared the intersection when it slowed to a crawl. Any reasonable human (or AI) would accept that as a clear intersection. Even if the car in front of me had stopped at the green light, waited for the Google car to clear the intersection, and then proceeded, they still would have been stuck. Unless, of course, your interpretation of your made up rule is that intersection plus one car length beyond the intersection must be clear on a green light before the next car can enter the intersection.
Your comment also shows why the legal framework will probably be the last to be settled before self driving cars become commonplace. "My code followed the letter of the law" won't work - laws are ambiguous and contradict each other and context often matters.
My feeling is that we're "20 years" away from general, broad deployment of self driving cars, mostly because we don't know how they will work when taken out of the hands of the developers and given to the general population.
There's nothing preventing self-driving cars from working just fine in highly controlled situations - local shuttles on private property, maybe in bus lanes. We'll probably see some form of that first, along with self-driving features augmenting car's control systems (adaptive cruise controlling being one that we already have). I hope we see some of these applications in the next 5 years.
But, it's all the things that never occurred during testing that turn out to happen regularly in a broad deployment that will slow down general adoption. Not just in dealing with road hazards, but also in dealing with how everyone else drives.
My personal anecdote with a Google car in Austin highlights this: I was crossing a major street (Burnet) from a side street and was two cars behind the Google car. The Google car crossed with a green light and I entered the intersection with a green light. The Google car quickly slowed down and almost stopped in the middle of the lane immediately after crossing the intersection, leaving me and the car in front of me stranded in the intersection as the light proceeded to change. I doubt the Google car driver ever realized the hazard they created.
Beyond that, there's the liability issues. Self driving cars will kill people, that's a given. We can argue forever about whether or not their programming and decision making/judgement is better than a human's, but the fact remains that accidents will happen that are the direct result of decisions made by the car's software. Until the legal framework for handling this is worked out, even perfectly functioning self driving cars will have a hard time with broad adoption. The legal system moves slowly and it will likely take 5-15 years for these issues to be worked out to everyone's satisfaction.
So, "20 years" is probably right for some definition of "20 years".
If you happen to work at YouTube: my one request is a simple setting that lets me flag the account as one that is used by the whole family. That alone should give you enough to target ads more effectively.
Also note that I'm not complaining about ads - just that they're not appropriate and YouTube's current (machine learning? auction based? ???) algorithm doesn't work very well.
That really doesn't explain the completely inappropriate ads my kids keep getting on YouTube. Our viewing history is almost entirely Minecraft videos, Disney Cartoons, and Katy Perry videos. Even I could write an algorithm to figure out that it's probably kids watching the videos (of course, I have a Ph.D. in this stuff, so that's not quite fair;) ).
My kids are the YouTube consumers in the house. One of them loves Minecraft videos. Let's just say that YouTube's choices of ads with those reflect zero knowledge that there's a 6 year old viewing them.
And don't tell me to use the YouTube kids app. It overfilters in most cases, but also underfilters.
Maybe let me set preferences if you're going to force ads on me? Or at least note my time zone and select ads based on the old-school network rules for what's appropriate at certain hours of the day?
Docker has introduced some wonderful security holes into the cloud ecosystem. Given its heavy use in many environments (and downstream use by well meaning individual users), it provides a wonderful backdoor that intelligence agencies will have access to for years to come.
Even without the obvious root filesystem access issue (which Docker likes to brush aside as "well, you can do that with a VM, too"), there are still thousands of Docker images out there running unpatched versions of libraries.
While the architects may not have grasped the intricacies of network topologies and how they impact rack layout and design, there's no reason another round of architects couldn't take that into account and actually design a tower that would work.
I'd imagine something more again to a giant smokestack with servers arrayed on the outside and cabling in the middle. The radius of the stack could be set to accommodate rings of servers with fast local interconnects (torus and star patterns within each ring). A "spinal cord" down the middle could provide a high-bandwidth backbone for the stack.
Ropes for rappelling/ascending could give people access to anywhere and a network of cable lifts on the outsides could lift heavier loads for installing hardware.
Just riffing here, but there are probably some designs that would work great and be cost effective, as along as you start the design from the perspective of building a giant computer first.
Slashdot Mirror
Uber and Lyft are in no way representative of free market principles.
In a free market, I need a ride somewhere, I put out a bid for what I'm willing to pay for that ride. If a driver likes my offer, they can accept it or counter. That's free market ride sharing.
Uber is simply a market for rides regulated by Uber, just as taxi services are markets for rides regulated by governments. You, as the rider, are completely at their mercy for setting your fare. Drivers are also completely at Uber's mercy for setting their rate. That's the opposite of a free market.
Even if you look at it from the service perspective of allowing ride sharing companies to create competing ride markets, Uber fails. Uber is heavily subsidized by its investors and foreign governments (Saudi Arabia's $3.5B investment, for example) and has never had to compete on costs. Again, something antithetical to free market principles.
Of course, just like I had Pets.com deliver 50lb bags of dog food for free in 1999 and used Instacart until they jacked up their rates, I'm happy to spend investor's money on cheap rides. No point in missing out on the party while it's happening.
-Chris
When Uber and Lyft stomped out of Austin like whiney, spoiled brats, the free market stepped in a started creating alternatives. One of them is a non-profit:
http://www.austinchronicle.com...
I haven't used it yet, but I like the idea of non-profit or B-Corps competing side by side with the for-profit companies.
-Chris
"Earlier this month the site compared this year's drunk driving arrests to last years -- and discovered that in the three weeks since Uber and Lyft left Austin, 7.5% more people have been arrested for drunk driving."
Keep in mind that that was a 6 week sample in absolute terms (not relative to population growth or corrected for any other factors, like more aggressive policing, festivals/events that could have spiked rates, weather, etc - it was just raw year-over-year numbers). It's bad statistics. It's been a bit depressing to watch so many techies (including many of my data science friends who should know better) blindly believe Uber/Lyft's messaging.
I live in Austin and I'm really sick of the Uber/Lyft propaganda machines. All they're doing is spending their VC money on lobbying and lawyers to mold communities in their image rather than trying to develop a service that actually works with the communities they serve (seriously: they spent $9MM trying to influence a local election. What a waste of some investor's money.) Uber is just a grand VC experiment in seeing how they can run illegal businesses and force laws to change for them. They tried it in health (23andMe, Therenos) and found the FDA to be a formidable opponent and instead went after an unpopular industry (taxis) to develop their playbook. Once they work out the playbook with taxis, they'll go after other regulated industries.
Remember, Uber and Lyft were not forced out of Austin. They simply left because they didn't want to play by the rules. They could have stayed. What's exciting is that the market is working and a whole new crop of TNCs are evolving in Austin that are willing to work with the community rather than against it.
And don't get me wrong, I love the idea of TNCs. They're great services, they just need to play by the same rules as everyone else and when those rules don't seem to be right, work with the community to find ones that do (compromise is part of that). Right now, Uber and Lyft are just acting like that spoiled rich kid you knew growing up who was never held accountable for his actions.
-Chris
Tell me what part of the US a roughly $26k annual salary is a "great deal"?
-Chris
Interesting what you did there, calling the $13.00 after expenses a "profit". What's left out in the expenses is the salary for the contractor. That $13.00 is their take home pay after the expenses of running their car. So, if you have zero living expenses and don't eat, then sure, call it profit. But since Uber drivers are humans, they actually need food and shelter. Some of us also think that all humans should have a decent standard of living and have a decent work/life balance, not just those of us that can make six figures surfing the web all day and occasionally banging out a few lines of code.
$13.00 take home pay equates to roughly $26k/year (using the standard 2000 hour work year that every software person I know uses to compute their "salary" based on their consulting rate). The poverty line in the US is roughly $23k.
tl;dr: the $13.00 is not profit, it's salary; $13/hr won't even let you save and the US deems that salary the bare minimum to just scrape by. Working more destroys the work/life balance.
-Chris
FTA,
"Apple declined to comment on why it didn’t follow its usual procedure."
Someone did ask, Apple didn't say anything.
Which is Apple's usual procedure (not responding). Heck, even within Apple engineers aren't allowed to share details like this outside of their immediate team.
But, as many other posts have pointed out, the source code for most of the kernel is already open source and iOS was unencrypted until iOS 8. Not really much to see here...
(on a side note, what's up with /. suddenly becoming just a string of "gotcha" stories about software bugs and corporate mistakes?)
All of them? When I contract, I tell my prospective customers my rate and they can either work with me, offer a different rate, or look for a different contractor. Uber drivers don't have this flexibility.
-Chris
Probably not, but...
If you remember the dot com bust, there were a few precipitating events that got everyone looking closer at sky-high valuations. Enron is probably the most important of those. While Enron wasn't a dot com, they used some very creative accounting practices to book revenue and inflate their value (innovative, disruptive, new economy, and all that). Their crash helped highlight the funny math going on at internet companies and helped get investors and regulators asking the hard questions.
The current bubble has a few possible candidates for an Enron-style scandal. I've thought that Theranos might be it - they fit the broader narrative of youthful founders disrupting stodgy industries and minting new billionaires. Then there's Uber, but they have enough investor money in the bank to hide any structural issues with their business model for years. Palantir is another that may help burst the bubble as they learn that the outrageous consulting rates and blind faith in their methods they received from the military are difficult to replicate in the business world when you have some level of accountability to shareholders and customers. They have less cash than Uber to mask their situation much longer.
But, maybe it will be just like before: good old math that no longer adds up. At some point, all the SaaS companies using the clouds will run out of credits and goodwill from the providers and be asked to pay real rates for the services (just in case you don't know: almost no SaaS company actually pays for their hosting on the major cloud providers for the first year or so, and even then they pay deeply discounted rates. And if you're at a SaaS paying full rates to Amazon or similar, you need to call your rep - your competition is paying less than you. The cloud providers do this in hopes that strong businesses will emerge that they can eventually reap profits from - Salesforce is the classic example). I'm guessing* that all the major cloud providers are using some form of funny math to hide this.
So, Oracle's probably not going to suffer the fate of Enron. But, just like in the last bubble, "clever" accounting may be what finally pops it.
-Chris
*ok, I know from direct experience how at least two of them are doing it, and yes, they're doing it
Of course existing infrastructure is bad for hydrogen, but upgrading existing infrastructure is part of the benefit for the hydrogen crowd. While the physical elements of our current infrastructure definitely won't support hydrogen, the business infrastructure is already in place to match the existing fuel distribution model. A one-time cap-ex investment to swap out fossil fuel infrastructure components with components that can support hydrogen is all that is needed to maintain the existing business model. Sure, it won't be cheap, but it will likely be a supported by tax incentives (create local jobs to do the retrofit, write off retrofit) and it provides an opportunity for the oil service industry to learn hydrogen infrastructure by developing it on the taxpayer's dime.
Don't think about this like a financial engineer, not a civil engineer. It doesn't matter what makes the most sense from a technical perspective, what matters is not disrupting cash flow for entrenched industries. I didn't really appreciate this argument until I started running a company. But after spending the last four years around finance people, I have a new appreciation about how they (and by extension, most businesses) view the world. They optimize around profits, not technology.
-Chris
Where are mod points when I need them???
This. This. This!
I remember talking with my grandfather years ago about the future of energy for cars. He's a EE who ran a telecom infrastructure company for years and always saw things from the infrastructure perspective. Whatever was least disruptive to the energy ecosystem as a whole was going to win. Given the entrenched players at every stage in the distribution chain, hydrogen made the most sense. Each industry segment would profit greatly from upgrading their infrastructure to support hydrogen while not having to abandon their place in the process.
Electric cars upend multiple industries - from oil services all the way to convenience stores. Change will be fought tooth-and-nail. I just hope Elon doesn't run out of cash before he's had a chance to force the issue on electric cars.
-Chris
Your points are why I think we need to have a broader discussion about this.
Historically, "open" specifications were industry designed "APIs" that enabled interoperation between multiple implementations. However, implementing them required a license and/or certification from the organization that maintained the spec. The specs were published and implementations were encouraged, but only under specific terms. Of course, the availability of the specs did wonders for technology and competition. Pretty much everything we rely on today from networking, to hardware, to graphics, to sound processing evolved this way.
As we transitioned more to software APIs, certification requirements became less important (a bad API implementation isn't going to cause a fire). APIs also tended to be more tightly coupled with a single implementation. Competition usually evolved in the form of a new implementation/API (e.g., QT vs. GTK vs. wxWidgets to pick a somewhat recent example) rather than something that was API compatible. In fact, most APIs out there will only ever have one implementation.
Developing a spec or API that's truly general purpose and usable for interoperability is time consuming and costly. The old approach accounted for this by designing them through industry funded organizations with all parties going in knowing they would benefit. Software APIs, by and large, are developed by one person or a small group on their own dime. If their API is generally useful and manages to succinctly capture a problem domain in a way that would benefit from multiple implementations, they should be compensated for that effort.
At a higher level, society doesn't have any more right to the API than it did before it was developed. The simple fact that it does benefit society proves that the design was valuable. Again, the developer should be compensated and society should gain (we need to stop thinking these two things are mutually exclusive). This also is the general basis for our intellectual property laws - creators are granted a term of exclusivity in exchange for sharing their work with the world.
I understand the desire to have instant, free access to every great idea. But, as a creator, I also see it from the other side.
-Chris
The musical notation is the character set you use to communicate the melody. Saying notation is like an API is like saying ASCII or UTF-8 is an API.
I agree that a good part of the software industry will be impacted by allowing APIs to be copyrighted and it may be detrimental in many cases. But, as this case is demonstrating, it's a conversation we need to have as an industry. We need to decide if creators have the right to protect their intellectual property and, if so, under what provisions they can that provide the best balance between creator rights and user rights.
-Chris
"And why do you think they're going through the effort to keep the prices low?"
To wipe out the competition and then raise prices when there's no more competition. Pretty much what every good capitalist wants to do.
The only competition Uber and Lyft they have at the low end of price spectrum is each other. Of course, they need each other in the same way Intel needs AMD - to demonstrate to regulators that they aren't a monopoly. The competition they need to wipe out is taxis and other TNCs (transportation network company) that pay fair wages and follow the laws. Wiping out taxis is pretty easy, since there have been structural issues with the taxi business for decades. Wiping out the other TNCs is going to be a little harder since the new services are demonstrating that you can run a TNC that follows the law and pays its drivers a reasonable wage.
As Austin will likely demonstrate, the race to the bottom in compliance and wages being run by Uber and Lyft is probably not the real race to provide alternatives to taxis. Business that respect their drivers, communities, and passengers will emerge as the winners here.
-Chris
No, they're cheap because they're burning through piles of cash from their investors and a (limited, but still large) pool of drivers willing to work a few months before they realize they got a bum deal. Both will run dry, at which point the TNC experiment will end.
For a really good discussion on the economics from the driver's side, check out any of the recent reddit threads in Austin discussing Uber and Lyft's decision to cut off 10k drivers and split town. Here's one to get you started: https://www.reddit.com/r/Austi...
-Chris
Ok, I'm going to take a slightly unpopular stance here and suggest that APIs probably should be copyrightable.
Ignoring all the legal issues, my rational is simple: An API spec represents the output of the intellectual effort of the architect far better than any implementation code. Designing a good API is difficult. Doing so requires finding exactly the right abstractions to allow users to use your API to perform complex operations in a simple, straightforward manner. The design process often involves several iterations of implementation to refine the API - not only implementing the functionality, but writing software that uses to to make sure it meets its goals.
The book title/chapter title argument is often used to show why APIs shouldn't be copyrighted. That's a poor analogy. Many books don't bother with chapter titles, so they're clearly not essential to the interpretation of the material. When present, they usually can't be used to quickly summarize a book. A well designed API will clearly and concisely present to you everything the underlying library can do. In fact, you should never care about the implementation of the library. If you ignored the text of a book, you wouldn't really be reading it.
If we're going to look to artistic pursuits for analogies, I'll suggest music is a better one. Melodies and lyrics are primarily what's copyrightable in music. Chord changes and musical embellishments are not. Arrangements are copyrightable when written down. Specific performances are also copyrightable (which is why samples must be cleared for use in other songs). Melodies and lyrics are akin to an API - the instantly let you identify the song/library and are the primary way most people remember it. For example, I can play "Yesterday" on a piano, guitar, speak-and-spell, and it's still a Beatles song. I still owe the Beatles royalties for using their lyrics and melody, regardless of how I arrange and perform it.
Now, if we allow APIs to be copyrighted, we gain a lot of flexibility. Most importantly, the copyright holder can release the API under a free and open license if they want. The designer can say: here's my work, feel free to do with it what you want. Or, they can lock it down and restrict what can be done with it.
For better or worse, Sun wanted the best of both worlds with Java. They implied that it was free and open, but never actually released the APIs under a specific free and open license. In the music world, the "Happy Birthday" saga is similar. The melody and lyrics were thought to be under copyright and Warner collected a few million a year from artists for performing it and using it in their works. Just like the core Java APIs, everyone knows "Happy Birthday" and most people used it casually without paying royalties (yes, I realize not everyone knows Java, but most readers of /. do). With the song, it turned out an earlier version that wasn't under copyright was found, which invalided Warner's claims. Unfortunately, that's unlikely to happen with Java.
tl;dr: APIs are the creative output of the design process, just like melodies and lyrics are in music. They probably should be copyrightable.
-Chris
One person's trash is another's feast. Most of the music on the radio is actually quite good, if you're a fan of music and not just a fan of one particular genre. Pop music, for all its commercial faults, is popular for a reason. People like it.
Sure, classical and folk are good, too. So is jazz, rock, EDM, noise (yeah, it's a genre), and just about every other style people have come up with.
I challenge you to listen to some EDM and compare it to your favorite classical pieces. While we have had 300+ years to study classical music to death, the overall structure of the music is pretty much the same as EDM: invent a theme/hook, make some variations on it, connect the variations together for dramatic effect, embellish it all using the underlying implied chordal structure by overusing arpeggios ;).
Folk and Pop basically have the same relationship. Both tend to have rigid rules around song structure (ABAB,ABCAB, etc), use simple chord changes (almost always some mix of I, IV, V in both genres), and have lyrics that resonate with the listener base. Interestingly, they're also controlled with an iron fist by the powers in the genres - just try developing a new folk song without approval of the keepers of the Great American Songbook. ;) (I play in a country/folk band, the powers-that-be are almost as annoying as those from the jazz world, where I've also spent a lot of time)
The meta point being: Across genres, music is more similar the different. I encourage you to go on a listening bender across your local FM stations and seed a few Pandora stations with random things.
Huh? H1-Bs aren't citizens and can't vote. It's only when you get citizenship that you can vote. The number of new citizens nationally is only in the mid hundreds of thousands each year, so not enough to impact elections. (source: https://www.uscis.gov/archive/...)
Liberal Democrats (at least all that I know, and I live in Austin, so that's pretty much everyone I know) tend to support immigration for humanitarian, not selfish reasons.
-Chris
Two points:
1) On a green light? Please show me the citation to Texas law that says that only one car is allowed in an intersection on a green light (yes, I'm calling BS on your claim and putting the burden of proof on you). I'm pretty sure that's the rule for intersections controlled by stop _signs_, but it's not the rule for stop _lights_.
2) The Google car had already cleared the intersection when it slowed to a crawl. Any reasonable human (or AI) would accept that as a clear intersection. Even if the car in front of me had stopped at the green light, waited for the Google car to clear the intersection, and then proceeded, they still would have been stuck. Unless, of course, your interpretation of your made up rule is that intersection plus one car length beyond the intersection must be clear on a green light before the next car can enter the intersection.
Your comment also shows why the legal framework will probably be the last to be settled before self driving cars become commonplace. "My code followed the letter of the law" won't work - laws are ambiguous and contradict each other and context often matters.
-Chris
My feeling is that we're "20 years" away from general, broad deployment of self driving cars, mostly because we don't know how they will work when taken out of the hands of the developers and given to the general population.
There's nothing preventing self-driving cars from working just fine in highly controlled situations - local shuttles on private property, maybe in bus lanes. We'll probably see some form of that first, along with self-driving features augmenting car's control systems (adaptive cruise controlling being one that we already have). I hope we see some of these applications in the next 5 years.
But, it's all the things that never occurred during testing that turn out to happen regularly in a broad deployment that will slow down general adoption. Not just in dealing with road hazards, but also in dealing with how everyone else drives.
My personal anecdote with a Google car in Austin highlights this: I was crossing a major street (Burnet) from a side street and was two cars behind the Google car. The Google car crossed with a green light and I entered the intersection with a green light. The Google car quickly slowed down and almost stopped in the middle of the lane immediately after crossing the intersection, leaving me and the car in front of me stranded in the intersection as the light proceeded to change. I doubt the Google car driver ever realized the hazard they created.
Beyond that, there's the liability issues. Self driving cars will kill people, that's a given. We can argue forever about whether or not their programming and decision making/judgement is better than a human's, but the fact remains that accidents will happen that are the direct result of decisions made by the car's software. Until the legal framework for handling this is worked out, even perfectly functioning self driving cars will have a hard time with broad adoption. The legal system moves slowly and it will likely take 5-15 years for these issues to be worked out to everyone's satisfaction.
So, "20 years" is probably right for some definition of "20 years".
-Chris
But are they Web Scale???
And, what's the appropriate label for the units: T$, Tusd, TUSD, ...?
-Chris
If you happen to work at YouTube: my one request is a simple setting that lets me flag the account as one that is used by the whole family. That alone should give you enough to target ads more effectively.
Also note that I'm not complaining about ads - just that they're not appropriate and YouTube's current (machine learning? auction based? ???) algorithm doesn't work very well.
-Chris
That really doesn't explain the completely inappropriate ads my kids keep getting on YouTube. Our viewing history is almost entirely Minecraft videos, Disney Cartoons, and Katy Perry videos. Even I could write an algorithm to figure out that it's probably kids watching the videos (of course, I have a Ph.D. in this stuff, so that's not quite fair ;) ).
-Chris
My kids are the YouTube consumers in the house. One of them loves Minecraft videos. Let's just say that YouTube's choices of ads with those reflect zero knowledge that there's a 6 year old viewing them.
And don't tell me to use the YouTube kids app. It overfilters in most cases, but also underfilters.
Maybe let me set preferences if you're going to force ads on me? Or at least note my time zone and select ads based on the old-school network rules for what's appropriate at certain hours of the day?
-Chris
Docker has introduced some wonderful security holes into the cloud ecosystem. Given its heavy use in many environments (and downstream use by well meaning individual users), it provides a wonderful backdoor that intelligence agencies will have access to for years to come.
Even without the obvious root filesystem access issue (which Docker likes to brush aside as "well, you can do that with a VM, too"), there are still thousands of Docker images out there running unpatched versions of libraries.
-Chris
While the architects may not have grasped the intricacies of network topologies and how they impact rack layout and design, there's no reason another round of architects couldn't take that into account and actually design a tower that would work.
I'd imagine something more again to a giant smokestack with servers arrayed on the outside and cabling in the middle. The radius of the stack could be set to accommodate rings of servers with fast local interconnects (torus and star patterns within each ring). A "spinal cord" down the middle could provide a high-bandwidth backbone for the stack.
Ropes for rappelling/ascending could give people access to anywhere and a network of cable lifts on the outsides could lift heavier loads for installing hardware.
Just riffing here, but there are probably some designs that would work great and be cost effective, as along as you start the design from the perspective of building a giant computer first.
-Chris