Apple pay isn't on android, by definition. Unless you're talking about the competing Google Pay, which is a different competing standard.
You mean Android Pay, not Google Pay. And it's not a different, competing standard. Both Apple Pay and Android Pay use the same NFC technologies and standards.
On the name, I should point out that it's somewhat understandable that you call it "Google Pay", since Android Pay is a successor to Google Wallet, which was Google's original NFC payment solution, released in 2011 (long before Apple Pay). The Google Wallet approach was a little different, though. Because of payment network limitations, Google used a "proxy card" solution, where a Google-issued credit card was what was actually used to pay at the point of sale, and Google then charged your credit card on the backend. That approach had problems both for the user, who might not get full credit from rewards cards, and for Google, who lost money on every transaction due to the difference in fees between the card-present transaction at point of sale, and the card-not-present transaction used for user's payment, but had the supreme advantage that it would work with any credit or debit card. Banks also really disliked the proxy card solution because it threatened to take too much control of the payment systems away from them. With the intermediate routing step Google could have arranged to use any payment system on the back end, and then used its clout to get the point of sale updated to a solution that didn't involve the banks, and removed the banks from the process completely. There's no evidence Google was going to do that, but the banks were afraid of it and chose to make Google's life very hard in all sorts of ways around the NFC proxy card (and its physical, plastic analogue, which Google issued for a while).
Apple waited until networks were ready to do "network tokenization", and until some more banks were ready to handle NFC transactions, both of which are required to enable the Apple Pay model where the payment is done directly against the user's card, with payment clearinghouses routing the the transaction directly to the bank that issued the credit card. Android Pay uses this same model, with the difference that if you have a credit card which was previously used with the Google Wallet proxy card solution, Google "grandfathers" your card in and continues using the proxy. This direct model fixes the disadvantages of the proxy card solution, but means that you can only use cards whose issuers have set up the necessary infrastructure. But these days, lots of them have. In particular, the big bank service providers like First Data have got everything set up so their clients who issue credit cards can do NFC. This means that nearly all small banks and credit unions can do it, and most of the big banks can do it. Some of the big banks, and many of the medium-sized banks still aren't set up.
(Note that I've intentionally left out some details, like the first version of Google Wallet using a direct, non-tokenized approach that only worked with one bank, and some of the other intermediate steps. I figured this was long enough.)
I agree. Talk to your device manufacturer about their bug, but I don't expect them to listen to you. If you want to avoid that bug, you have to buy a device from an OEM that allows unlocking. If enough people voted with their wallets in this way OEMs *would* listen, and non-unlockable bootloaders would disappear.
If Google had designed (? or something?) Android so that updating the base OS was something that could be pushed direct from Google instead of from each manufacturer's bollixed version of the system, there'd be no problem for any of us.
That may seem obvious now, but it's far from clear that Android would have succeeded the way it has if OEMs hadn't been allowed to differentiate their versions. That was (and is) something that's important to them, and they may well have decided that they wanted to do their own thing instead if Google hadn't given them the degree of control they wanted. Or maybe they'd have adopted Windows, since while it wouldn't allow them to customize it would have had the advantage of being from the then-biggest OS maker around.
It seems very likely that the ability of OEMs to customize was a core component of what made the Android ecosystem successful.
Also, keep in mind that the only way Google could really have kept OEMs from modifying Android however they like would have been to keep it closed. Personally, I'm glad that Google made the choices it did, not because I'm a Google employee working on Android (though I am), but because I've been an open source and free software advocate since before Google even existed. Android is far from perfect, and devices aren't as open as I would like, but I think the mobile software world is much better than it would have been without a F/LOSS mobile OS.
I still think that two years of updates is outrageous forced obsolescence that is prematurely adding electronic garbage to landfills.
FWIW, it's actually two years of upgrades and three years of security updates on Nexus devices.
I'm seriously considering going back to an iPhone on my next phone upgrade, despite all the concerns I have about them too. They at least support their hardware for around 5 years.
At least they have done so in the past. Note that they've never made any commitment to that, so they could stop.
Unless you bought a device with an unlockable bootloader, any way that you can get root is a bug, not a feature. It may useful to you, but it would be equally useful to an attacker.
The central banks of the world are conjuring money out of thin air and using it to buy stocks
Cite? I'm not aware of any central bank buying stocks. The "quantitative easing" they're doing -- AFAIK -- is all bond purchasing, which means they're not buying ownership in real businesses, they're lending money to real businesses.
Concurrently, interest rates are artificially low
That's debatable. Without the actions of the central banks, we would likely be in a deflationary cycle. Assuming interest rates naturally adjusted accordingly, they should go very low, or even negative. Some of the central banks have gone to slightly negative interest rates, but they won't go nearly as negative as would naturally occur in a deflationary cycle. Instead, they're pumping money into the economy (via QE) to avoid deflation.
You are confusing contributing with leading the project.
Determining what code is written, what new features are developed, is leading the project. Not merging the contributions after ensuring the code is well written.
Linus leads from behind. After a feature is developed, he decides whether it will be allowed into the kernel. It's the same sort of decisionmaking process as in most development workflows, it just front-ends most of the work.
In most development processes, someone will decide "the product should do X", and they'll make some slides and pitch the ideas and the leaders will decide whether or not to pursue it. If they decide to pursue it then the developers will build it, debug it, test it, etc. The process is optimized around conserving a scarce resource, developer time.
In the Linux process, someone decides "Linux should do X", and so they build it, write all the code, debug it, test it... and then they'll send it to Linus, who decides whether or not to merge it. Same process, the difference is that the leader decides on the basis of fully-implemented code, rather than slideware. In the Linux model, developer time is not scarce and the process does not optimize for conserving it.
I don't know and there's no point in baseless speculation. I would guess it would be something like a security chip in the Nexus 5 isn't compatible with the new secure boot mechanism, but again, I have no idea.
No, it's nothing like that. There are some security-related features that are improved on the new devices, but those in and of themselves wouldn't block upgrades.
It's actually pretty simple. Google has committed to supporting devices for three years, and the Nexus 5 is more than three years old. If you really want to run Nougat on a Nexus 5, though, you can do it. Just unlock the bootloader and flash it yourself.
what benefit will that give when most of the energy is consumed for the display?
That depends on your usage model, and on your display settings (most importantly, how long the screen stays on when you're not using it).
For most people the display is the biggest single consumer of power, but the combined radios (cellular & Wifi) are almost as big, and radio + CPU power consumption is considerably larger than display consumption. Doze mode conserves radio and CPU power, and for most people does provide a big increase in battery life.
This isn't the case if, for example, you spend a lot of time playing (CPU-light) games or reading books or other uses that keep the screen on for hours but don't use a lot of CPU or data. In that case, Doze mode won't do you much good because you're keeping the screen turned on all the time.
you'd still only see a 25% battery time increase at best.
A 25% increase is huge. The way batteries are sized in phones, most users get around 12 hours or so. Say, 6AM to 6PM. If you increase that by 25% you now get 15 hours which is very close to a full day. Make it 30% and you have a device that only needs to charge while the user is sleeping, in most cases. Given that most smartphone users have already arranged to plug their phones in at various points in the day (while commuting, etc.), even a 20% increase in many cases is enough so users find that their phone always has plenty of battery.
Now we use them as VR systems, which will drive the need for faster phones with better displays and better positional tracking for years to come.
Is this a need, or is this a want?
That question is irrelevant. If I want to have a device that does something, and I want it enough to shell out the money for it, why in the world shouldn't I?
Your whole premise is that people are somehow wrong if they want a shiny new phone every year. Who are you to tell people what they should want?
Except... it wasn't a systemd bug at all. Per comment #16:
Ok, with everyone confirming that the systemd patch is not required, I am closing the systemd part of the bug as 'Invalid' - let's only concentrate on the dbus part here. That being said, I would not like to release a new patch for dbus downstream if the patch hasn't been fully reviewed and approved upstream.
In this case I would propose to wait a bit and see if a finalized patch will be available.
Not that the presence of one bug in systemd would indicate that the whole approach is a bad idea... but it's rather funny that the one example you pick turns out not to be a systemd bug at all.
Then you somehow missed that viewing distance is dependent on application, not pixel size. It makes no sense to move your phone further away so you can't see the pixels. Instead, pixel size should be decreased until the display provides perfect clarity at expected viewing distances -- which may be one inch if you're using your phone as a VR display.
With 1280x720, you can display more readable text than with 960x640. This is true no matter the screen size.
False. If the screens are at a distance where the 960x640 screen has sub-arcminute pixels, then the 1280x720 display will not allow you to display any more readable text. The minimum readable font size will be the same on both screens, and in fact you will not be able to distinguish any difference between them.
Actually, what you really need is sufficiently-high angular resolution. The angular resolution of the eye is about one arcminute, or 0.0003 radians. You need pixels to be smaller than that so everything is smooth. Call it 0.0002 radians to be completely sure. At a viewing distance d, therefore, you need pixels that are tan(0.0002) * d or less in size. Close to zero, the tangent function is essentially a straight line, so that means you need pixels 0.0002d in size or smaller. Assuming you're measuring distance in inches, that means you need 1/.0002d = 5000/d DPI.
So, at an 18" viewing distance, you need 5000/18 = 278 DPI. At a 180" viewing distance (e.g. home theater), you need 5000/180 = 28 DPI. At a 6" viewing distance you need 833 DPI. Six inches is a closer than people use their phones most of the time, but not always. I see (young) people watching movies on their phones at that distance (us oldsters would need reading glasses). At a 1" viewing distance (e.g. Google Cardboard) you need 5000 DPI to be sure of indiscernible pixels.
I expect mobile display pixel densities to continue rising, into the thousands, to support VR headset use.
Very welcome. Read that book... it's an eye opener. I find it sad, but unsurprising, that none of that history was covered in any of my classes in school.
Then you wonder why your bigoted policy ends up with lots of incompetent diversity candidates.
That is only a problem if you lower your standards to achieve diversity. It is possible to maintain standards while favoring minorities if you do it by casting a wider net. That's easier said than done, of course.
government sanctioned segregation and racism as recent as 50 years ago, and slavery just over 100
There's a very good argument that slavery didn't actually end until the 1940s, and it was even *more* government-sanctioned from the 1880's to 1940's than it was before the Civil War, since local government actually played a pivotal, essential role in post-emancipation enslavement. The antebellum form was government-approved but almost entirely private. Technically, the post-emancipation slaves were convicts working off court fees which had been paid on their behalf by a white farmer, mine owner, etc. who then got to use them as indentured servants for a period of time. Except that in many cases the indenture only ended in death and the initial "crime" was trumped up specifically to fill the need for manpower, or as a way to deal with uppity blacks. The court fees were set deliberately to ensure that poor blacks couldn't pay them and would have to provide years (at least) of labor. Oh, and there was no state oversight of living conditions, etc., meaning they were often far worse than had been experienced by antebellum slaves. Actual slaves were expensive capital assets, while convict labor was cheap enough it wasn't cost-effective to feed, house and clothe them adequately.
I can't fucking STAND when shit pops up in my face while I am focused because 99.999999999% of the time it's some fucking bullshit message.
What I can't stand is people who exaggerate by many orders of magnitude. A little exaggeration is okay, but when you pound on the '9' key like that, you're clearly not even thinking. For your above statement to be literally true, you'd have had to have experienced one trillion popups (~1050 per second, every second of your life, 24x7, for 30 years), of which exactly one was useful.
Again, it is the crappy attitude of the industry I am talking about, and the sad state of the code. If you are really, really passionate about coding (such as I am) you can muddle your way through it, but you have to be ultra passionate. I think every professional career requires dedication, but most have a lot more longevity and actually respect people who have been at it for a bit.
This is completely opposite of my experience in software development. I do see other areas of IT forcing older people out and being difficult places to build a life-long career, but competent software engineers are in high demand and age doesn't seem to matter a bit. Older engineers are expected to have higher levels of competence than young ones, sure, commensurate with their higher salaries, but if you can do the job there are lots of jobs available.
Maybe my perspective is skewed because I'm looking at my own peers who are towards the upper end of the competence scale? Software has been a great profession for me with great compensation, decent (and flexible) work-life balance, and work that is both challenging and rewarding. I've been doing this for more than 25 years now, and I fully expect to be gainfully employed at it for as long as I want to, probably another 20 years or so. I'm almost 50 years old, and my skills are in higher demand than ever.
I do have to say that if you want to succeed in this business, you need to both find your niche, and expect to continue learning, constantly. If what you want to do is settle into a comfortable routine, doing the same sort of work over and over again, you're probably going to have a tough time. You need to enjoy learning, and taking on new challenges. Maybe that's what you call "ultra passionate"? I call it "being interested".
Agreed. Wil Wheaton endorsing G+ was particularly disappointing, he's always struck me as someone who's genuine and down to earth. Just goes to show that anyone can be bought for the right price I suppose.
Wheaton used G+ quite heavily until about six months ago. I think he genuinely liked it.
For me, I don't have a charger at home (live in a condo with garage parking). I charge at work. So having the extra range means I don't need to fight for chargers as often. Right now, with a 85kWH battery, I find myself charging about twice a week (including the weekend trips) at work. If I can knock that down to once a week, it'd make a big difference to me.
Could you knock it down, though? How much amperage can your employer's chargers deliver? Most of them are limited to 30A, which means it's going to take better than 12 hours to get 80 kWh on board. If they support the J1772-2009 80A mode then your car can take 72A (17.2 kW) and you can get a full charge in 4-5 hours. Otherwise, you may have to plug in twice per week just because you can't get enough during a single session.
Slashdot Mirror
Apple pay isn't on android, by definition. Unless you're talking about the competing Google Pay, which is a different competing standard.
You mean Android Pay, not Google Pay. And it's not a different, competing standard. Both Apple Pay and Android Pay use the same NFC technologies and standards.
On the name, I should point out that it's somewhat understandable that you call it "Google Pay", since Android Pay is a successor to Google Wallet, which was Google's original NFC payment solution, released in 2011 (long before Apple Pay). The Google Wallet approach was a little different, though. Because of payment network limitations, Google used a "proxy card" solution, where a Google-issued credit card was what was actually used to pay at the point of sale, and Google then charged your credit card on the backend. That approach had problems both for the user, who might not get full credit from rewards cards, and for Google, who lost money on every transaction due to the difference in fees between the card-present transaction at point of sale, and the card-not-present transaction used for user's payment, but had the supreme advantage that it would work with any credit or debit card. Banks also really disliked the proxy card solution because it threatened to take too much control of the payment systems away from them. With the intermediate routing step Google could have arranged to use any payment system on the back end, and then used its clout to get the point of sale updated to a solution that didn't involve the banks, and removed the banks from the process completely. There's no evidence Google was going to do that, but the banks were afraid of it and chose to make Google's life very hard in all sorts of ways around the NFC proxy card (and its physical, plastic analogue, which Google issued for a while).
Apple waited until networks were ready to do "network tokenization", and until some more banks were ready to handle NFC transactions, both of which are required to enable the Apple Pay model where the payment is done directly against the user's card, with payment clearinghouses routing the the transaction directly to the bank that issued the credit card. Android Pay uses this same model, with the difference that if you have a credit card which was previously used with the Google Wallet proxy card solution, Google "grandfathers" your card in and continues using the proxy. This direct model fixes the disadvantages of the proxy card solution, but means that you can only use cards whose issuers have set up the necessary infrastructure. But these days, lots of them have. In particular, the big bank service providers like First Data have got everything set up so their clients who issue credit cards can do NFC. This means that nearly all small banks and credit unions can do it, and most of the big banks can do it. Some of the big banks, and many of the medium-sized banks still aren't set up.
(Note that I've intentionally left out some details, like the first version of Google Wallet using a direct, non-tokenized approach that only worked with one bank, and some of the other intermediate steps. I figured this was long enough.)
Non-unlockable bootloaders are a bug.
I agree. Talk to your device manufacturer about their bug, but I don't expect them to listen to you. If you want to avoid that bug, you have to buy a device from an OEM that allows unlocking. If enough people voted with their wallets in this way OEMs *would* listen, and non-unlockable bootloaders would disappear.
If Google had designed (? or something?) Android so that updating the base OS was something that could be pushed direct from Google instead of from each manufacturer's bollixed version of the system, there'd be no problem for any of us.
That may seem obvious now, but it's far from clear that Android would have succeeded the way it has if OEMs hadn't been allowed to differentiate their versions. That was (and is) something that's important to them, and they may well have decided that they wanted to do their own thing instead if Google hadn't given them the degree of control they wanted. Or maybe they'd have adopted Windows, since while it wouldn't allow them to customize it would have had the advantage of being from the then-biggest OS maker around.
It seems very likely that the ability of OEMs to customize was a core component of what made the Android ecosystem successful.
Also, keep in mind that the only way Google could really have kept OEMs from modifying Android however they like would have been to keep it closed. Personally, I'm glad that Google made the choices it did, not because I'm a Google employee working on Android (though I am), but because I've been an open source and free software advocate since before Google even existed. Android is far from perfect, and devices aren't as open as I would like, but I think the mobile software world is much better than it would have been without a F/LOSS mobile OS.
I still think that two years of updates is outrageous forced obsolescence that is prematurely adding electronic garbage to landfills.
FWIW, it's actually two years of upgrades and three years of security updates on Nexus devices.
I'm seriously considering going back to an iPhone on my next phone upgrade, despite all the concerns I have about them too. They at least support their hardware for around 5 years.
At least they have done so in the past. Note that they've never made any commitment to that, so they could stop.
Root.
Unless you bought a device with an unlockable bootloader, any way that you can get root is a bug, not a feature. It may useful to you, but it would be equally useful to an attacker.
From my experience, every update removes useful power user features.
For example?
The central banks of the world are conjuring money out of thin air and using it to buy stocks
Cite? I'm not aware of any central bank buying stocks. The "quantitative easing" they're doing -- AFAIK -- is all bond purchasing, which means they're not buying ownership in real businesses, they're lending money to real businesses.
Concurrently, interest rates are artificially low
That's debatable. Without the actions of the central banks, we would likely be in a deflationary cycle. Assuming interest rates naturally adjusted accordingly, they should go very low, or even negative. Some of the central banks have gone to slightly negative interest rates, but they won't go nearly as negative as would naturally occur in a deflationary cycle. Instead, they're pumping money into the economy (via QE) to avoid deflation.
You are confusing contributing with leading the project.
Determining what code is written, what new features are developed, is leading the project. Not merging the contributions after ensuring the code is well written.
Linus leads from behind. After a feature is developed, he decides whether it will be allowed into the kernel. It's the same sort of decisionmaking process as in most development workflows, it just front-ends most of the work.
In most development processes, someone will decide "the product should do X", and they'll make some slides and pitch the ideas and the leaders will decide whether or not to pursue it. If they decide to pursue it then the developers will build it, debug it, test it, etc. The process is optimized around conserving a scarce resource, developer time.
In the Linux process, someone decides "Linux should do X", and so they build it, write all the code, debug it, test it... and then they'll send it to Linus, who decides whether or not to merge it. Same process, the difference is that the leader decides on the basis of fully-implemented code, rather than slideware. In the Linux model, developer time is not scarce and the process does not optimize for conserving it.
I don't know and there's no point in baseless speculation. I would guess it would be something like a security chip in the Nexus 5 isn't compatible with the new secure boot mechanism, but again, I have no idea.
No, it's nothing like that. There are some security-related features that are improved on the new devices, but those in and of themselves wouldn't block upgrades.
It's actually pretty simple. Google has committed to supporting devices for three years, and the Nexus 5 is more than three years old. If you really want to run Nougat on a Nexus 5, though, you can do it. Just unlock the bootloader and flash it yourself.
what benefit will that give when most of the energy is consumed for the display?
That depends on your usage model, and on your display settings (most importantly, how long the screen stays on when you're not using it).
For most people the display is the biggest single consumer of power, but the combined radios (cellular & Wifi) are almost as big, and radio + CPU power consumption is considerably larger than display consumption. Doze mode conserves radio and CPU power, and for most people does provide a big increase in battery life.
This isn't the case if, for example, you spend a lot of time playing (CPU-light) games or reading books or other uses that keep the screen on for hours but don't use a lot of CPU or data. In that case, Doze mode won't do you much good because you're keeping the screen turned on all the time.
you'd still only see a 25% battery time increase at best.
A 25% increase is huge. The way batteries are sized in phones, most users get around 12 hours or so. Say, 6AM to 6PM. If you increase that by 25% you now get 15 hours which is very close to a full day. Make it 30% and you have a device that only needs to charge while the user is sleeping, in most cases. Given that most smartphone users have already arranged to plug their phones in at various points in the day (while commuting, etc.), even a 20% increase in many cases is enough so users find that their phone always has plenty of battery.
Now we use them as VR systems, which will drive the need for faster phones with better displays and better positional tracking for years to come.
Is this a need, or is this a want?
That question is irrelevant. If I want to have a device that does something, and I want it enough to shell out the money for it, why in the world shouldn't I?
Your whole premise is that people are somehow wrong if they want a shiny new phone every year. Who are you to tell people what they should want?
Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay
https://bugs.launchpad.net/ubu...
Except... it wasn't a systemd bug at all. Per comment #16:
Not that the presence of one bug in systemd would indicate that the whole approach is a bad idea... but it's rather funny that the one example you pick turns out not to be a systemd bug at all.
Yes I did.
Then you somehow missed that viewing distance is dependent on application, not pixel size. It makes no sense to move your phone further away so you can't see the pixels. Instead, pixel size should be decreased until the display provides perfect clarity at expected viewing distances -- which may be one inch if you're using your phone as a VR display.
With 1280x720, you can display more readable text than with 960x640. This is true no matter the screen size.
False. If the screens are at a distance where the 960x640 screen has sub-arcminute pixels, then the 1280x720 display will not allow you to display any more readable text. The minimum readable font size will be the same on both screens, and in fact you will not be able to distinguish any difference between them.
You didn't read the post you replied to.
Actually, what you really need is sufficiently-high angular resolution. The angular resolution of the eye is about one arcminute, or 0.0003 radians. You need pixels to be smaller than that so everything is smooth. Call it 0.0002 radians to be completely sure. At a viewing distance d, therefore, you need pixels that are tan(0.0002) * d or less in size. Close to zero, the tangent function is essentially a straight line, so that means you need pixels 0.0002d in size or smaller. Assuming you're measuring distance in inches, that means you need 1/.0002d = 5000/d DPI.
So, at an 18" viewing distance, you need 5000/18 = 278 DPI. At a 180" viewing distance (e.g. home theater), you need 5000/180 = 28 DPI. At a 6" viewing distance you need 833 DPI. Six inches is a closer than people use their phones most of the time, but not always. I see (young) people watching movies on their phones at that distance (us oldsters would need reading glasses). At a 1" viewing distance (e.g. Google Cardboard) you need 5000 DPI to be sure of indiscernible pixels.
I expect mobile display pixel densities to continue rising, into the thousands, to support VR headset use.
Thanks for the info!
Very welcome. Read that book... it's an eye opener. I find it sad, but unsurprising, that none of that history was covered in any of my classes in school.
Then you wonder why your bigoted policy ends up with lots of incompetent diversity candidates.
That is only a problem if you lower your standards to achieve diversity. It is possible to maintain standards while favoring minorities if you do it by casting a wider net. That's easier said than done, of course.
government sanctioned segregation and racism as recent as 50 years ago, and slavery just over 100
There's a very good argument that slavery didn't actually end until the 1940s, and it was even *more* government-sanctioned from the 1880's to 1940's than it was before the Civil War, since local government actually played a pivotal, essential role in post-emancipation enslavement. The antebellum form was government-approved but almost entirely private. Technically, the post-emancipation slaves were convicts working off court fees which had been paid on their behalf by a white farmer, mine owner, etc. who then got to use them as indentured servants for a period of time. Except that in many cases the indenture only ended in death and the initial "crime" was trumped up specifically to fill the need for manpower, or as a way to deal with uppity blacks. The court fees were set deliberately to ensure that poor blacks couldn't pay them and would have to provide years (at least) of labor. Oh, and there was no state oversight of living conditions, etc., meaning they were often far worse than had been experienced by antebellum slaves. Actual slaves were expensive capital assets, while convict labor was cheap enough it wasn't cost-effective to feed, house and clothe them adequately.
See: https://www.amazon.com/Slavery...
So, less than 100 years.
I can't fucking STAND when shit pops up in my face while I am focused because 99.999999999% of the time it's some fucking bullshit message.
What I can't stand is people who exaggerate by many orders of magnitude. A little exaggeration is okay, but when you pound on the '9' key like that, you're clearly not even thinking. For your above statement to be literally true, you'd have had to have experienced one trillion popups (~1050 per second, every second of your life, 24x7, for 30 years), of which exactly one was useful.
Again, it is the crappy attitude of the industry I am talking about, and the sad state of the code. If you are really, really passionate about coding (such as I am) you can muddle your way through it, but you have to be ultra passionate. I think every professional career requires dedication, but most have a lot more longevity and actually respect people who have been at it for a bit.
This is completely opposite of my experience in software development. I do see other areas of IT forcing older people out and being difficult places to build a life-long career, but competent software engineers are in high demand and age doesn't seem to matter a bit. Older engineers are expected to have higher levels of competence than young ones, sure, commensurate with their higher salaries, but if you can do the job there are lots of jobs available.
Maybe my perspective is skewed because I'm looking at my own peers who are towards the upper end of the competence scale? Software has been a great profession for me with great compensation, decent (and flexible) work-life balance, and work that is both challenging and rewarding. I've been doing this for more than 25 years now, and I fully expect to be gainfully employed at it for as long as I want to, probably another 20 years or so. I'm almost 50 years old, and my skills are in higher demand than ever.
I do have to say that if you want to succeed in this business, you need to both find your niche, and expect to continue learning, constantly. If what you want to do is settle into a comfortable routine, doing the same sort of work over and over again, you're probably going to have a tough time. You need to enjoy learning, and taking on new challenges. Maybe that's what you call "ultra passionate"? I call it "being interested".
Ah, yes, I was referring only to the Linux kernel. Yes, obviously you have to be a copyright owner to have standing to sue.
Agreed. Wil Wheaton endorsing G+ was particularly disappointing, he's always struck me as someone who's genuine and down to earth. Just goes to show that anyone can be bought for the right price I suppose.
Wheaton used G+ quite heavily until about six months ago. I think he genuinely liked it.
For me, I don't have a charger at home (live in a condo with garage parking). I charge at work. So having the extra range means I don't need to fight for chargers as often. Right now, with a 85kWH battery, I find myself charging about twice a week (including the weekend trips) at work. If I can knock that down to once a week, it'd make a big difference to me.
Could you knock it down, though? How much amperage can your employer's chargers deliver? Most of them are limited to 30A, which means it's going to take better than 12 hours to get 80 kWh on board. If they support the J1772-2009 80A mode then your car can take 72A (17.2 kW) and you can get a full charge in 4-5 hours. Otherwise, you may have to plug in twice per week just because you can't get enough during a single session.
Which ones? Hellwig can sue them, too. Actually he can't, unless he is the copy right holder.
He is a copyright owner of considerable chunks of Linux, which is why he's involved in this suit.
There wasn't any logic in my post, merely some statements of fact about the evidence that exists.