C++17 was mostly just an incremental improvement over C++14, which was an incremental improvement over C++11, and the most-anticipated feature -- Concepts -- didn't quite make it into 17. Still, the work of the committee is gradually evolving C++ into a much nicer language. Modern C++ code written according to the C++ core guidelines is simpler, clearer, safer, more maintainable -- and often more efficient.
Unfortunately, all of the old language features that are no longer recommended are still present, so the language as a whole is also becoming bigger and more complex... but if you can manage to purge all the old-style C++ from your codebase, the result is a language subset that's getting progressively easier to learn. Well, mostly. Template metaprogramming is becoming simpler and easier, but that's encouraging more and more of it, and there are still several non-obvious idioms needed to do common things. C++17 eliminates the need for a few of these, Concepts (which should, finally, land in C++20) will eliminate a lot more.
C++'s size and complexity mean that it must be used carefully. I often find myself asking people on my team to justify the clever metaprogramming constructs they create. Sure, it's cool to write a function that accepts an arbitrary number of arguments of any type, but if you only call it twice, and both times with the same number and type of args, why bother writing the complex templates that future programmers will have to laboriously parse? And if you call it many times with many different argument sets, you need to think about code bloat since the compiler has to generate another copy of the function for each argument set. So, a little discipline is essential.
But, assuming you can apply the necessary discipline, modern C++ is in a class by itself. It allows tremendously simple, expressive code that is also near-maximally efficient and obviously safe, with all memory accesses bounds-checked, and no possibility of either dangling pointers or memory leaks.
C++ is becoming awesome. I regularly spend time playing with competitors, such as Rust, and also often use dynamically-typed languages (e.g. Python, Java, C#). I've invested significant time into purely functional languages, notably Haskell. But for code that has to be efficient and precise, I keep coming back to C++ and it's getting better and better.
> transaction volume has increased beyond the design capacity.
Not if the re-designed features (SegWit, and Schnorr Signatures) were in use by everyone on the network.
FTFY.
The original design simply cannot scale. The proposed modifications would help, some. I think it's very unlikely that anything short of a complete redesign and restructuring could make it practical as a significant global currency.
But hey, we are still mostly on IPv4, there is a lot of inertia to overcome.
I can see a Walmart blockchain where they control 51% of the 'nodes'
They don't need that. All they need is a single server which signs all the blocks with a secret private key. Everybody with access can verify the data, but nobody else can modify it.
And each supplier could sign its own records in the chain with its private key. That would ensure that Wal-mart couldn't forge records from suppliers, and the hash chain would ensure that no one could rewrite history by removing or reordering records. It makes sense. What's not clear to me is that it's actually enough of an improvement to be worth the effort of retooling all of the existing automated systems.
Would you use a blockchain system when you needed to speed up transaction times? That's one of the claims of the article, and from everything I see, blockchain - BY DESIGN - gets slower and slower as more transactions are put into the chain.
Blockchains don't get slower as more transactions are added. What makes you think that? They don't necessarily even consume ever-growing amounts of storage, since it's always possible to agree to add some new records at the head summarizing information in the tail prior to some agreed-upon point in time, and then discard everything before that cutoff.
I'm sure you get this idea from bitcoin, but it's not accurate even for bitcoin. Bitcoin hasn't gotten slower on a per-transaction basis, it's gotten a little faster, and would be dramatically faster if it weren't for the changes made to intentionally slow down mining (note that mining is not an inherent feature of blockchains, though it makes sense for public blockchains). No, the problem with bitcoin transaction performance is that the transaction volume has increased beyond the design capacity. Transaction throughput is higher than ever, but transaction latency is through the roof because transaction demand is higher than throughput.
With that said, I really don't see how blockchains are going to help much, given that supply chains are already thoroughly automated. Right now, each party maintains a separate database and they exchange electronic documents for orders, invoices, etc. With blockchain they can create a shared ledger, but this seems like a minor win at best.
The "distributed" part is what is important, since it means that no one party can corrupt it.
That is how the current systems are setup.
It doesn't mean that Walmart can't setup an internal only "blockchain" that only runs on their intranet to track store balances.
Sure they can, but what value does it provide? A blockchain is more complicated and less efficient than a central database. If the concern is about having a single point of failure blockchains enable distributed consensus, but it's hard to see how that provides any value over a replicated database. It's hard for a well-placed employee to rewrite history with a blockchain, but that's also achievable with existing database technology, and in any case I don't see any evidence that it's a serious problem.
No, I see no value in a purely internal blockchain. There may be some value in using blockchains to establish distributed ledgers with partners (e.g. suppliers). Invoices, shipment records, receipt records, etc. could be stored in a blockchain so both parties are using a single distributed ledger rather than each maintaining its own database. Given that these sorts of processes are already thoroughly automated, though, it's not clear that a blockchain-based shared ledger would be that much better. My guess is that's the angle they're looking at, though, since it's the only thing that makes any sort of sense at all.
Better yet, call or show up at the hotel and offer cash. Works nicely for independent places -- they'll still need an ID and/or card for security, but they're willing to negotiate if you cut some of their costs (swipe, consolidator fees) out of the equation by paying cash.
If you arrive very late, offer to leave very early and to clean up after yourself so housekeeping doesn't notice the room was occupied, you can often pay a minimal fee directly to the front desk agent.
At least, that's what Jack Reacher does and everything in those books is clearly the truth.
Yes, it can be big deal if you leave your thermostat off then want to turn it on remotely when the weather turns cold. If you are away for a few days and temperatures drop below freezing that will be real big deal.
Is there a smart thermostat that doesn't have a safety temperature? Nest thermostats, for example, will by default not allow the temperature to fall below 40F, even if they're turned off. And really, why would you ever set them to "off"? The whole point of having a smart thermostat is so that it will do things like figure out when no people are around and lower the temperature to a reasonable minimum to save money.
So, really, the worst case here is that you're away for a while and your house cools to 40 degrees and because your Internet connection is shut off you can't turn the temperature up until you get home. So, it's still 40 when you get home and you have to wear a jacket for an hour or two until the house gets warmed up. So, the same as what you'd have to do with a "dumb" thermostat.
I'm looking for a decent smart doorbell. I'd like one that rings when someone who doesn't live in my house approaches the door. It should have a button for backup.
And a hacker is someone who enjoys making technology do interesting things. Good luck trying to redefine common language.
For that matter, this isn't even "common" language. Researchers in the field call it AI as well, and have for decades. When necessary they distinguish between strong AI and weak AI, but most of the time it's not necessary because strong AI doesn't yet exist.
Hey Elon, you can sell your horribly overpriced snake oil to the gullible "app" crowd but it's not going to work on TRUCK people.
I'm a truck person. My vehicle is a Ford F350, w/ a 6.7L diesel. My other car is a Nissan Leaf -- all electric.
Pickup trucks are about American steel and brawn, tugging a boat and your gun rack into the woods.
Actually, it's mostly Chinese steel, but yeah, my truck tugs a boat to the lake, a camp trailer to the woods, and a gun or three everywhere. Of course, my Leaf also hauls a gun everywhere, too.
Electric simply has no place, outside of a super-niche toy for.... Whom exactly? The people who have the $ to drop on a Tesla (rich liberals and techie wimps) likely aren't driving a truck in the first place.
I deposited $1K to reserve a Model 3, which is far from a "super-niche toy". My Leaf is fairly "niche"; its niche is "running errands around town and commuting" which isn't actually such a small niche. The Model 3 isn't niche at all, it's a solid performer that meets the needs of 90% of new sedan buyers.
As for pickups, I've been talking about how awesome an electric pickup would be for years. The torque and power of electric are ideal for trucks. Big, heavy, expensive batteries fit right in to big, heavy, expensive pickup trucks -- one-tons diesels like mine start at about $60K, decently-equipped, and weigh six tons. Range while towing heavy loads will be an issue. Mine has a 37-gallon tank which gives it 600 miles of range under "normal" conditions, not because anyone needs 600 miles of range, but because when you're hauling 10,000 pounds behind it that range is cut in half. BUT, pickups also have another advantage: a bed, which is an ideal place to put an ICE generator on those occasions when you need to extend the range. Which, frankly, isn't all that often. I'd like a generator with built-in jacks that I can back under and lower in place.
I do think an F150 replacement is the wrong angle, though. Working down from the semi is the right way. Big work trucks are expensive, heavy and require lots of torque. An electric can meet the needs of a work truck, and no one will bat an eye at a $60-80K price tag. The little half ton can come later as battery prices continue falling.
But in the stories my grandfather told me I sense a great deal of exciting things. To go to town they had to marshal their team of horses and brush them out afterwards, in the cold (you could see the horse's breath).
And an economist, though a bad one who knew little of economics and allowed his philosophy to drive his economic thinking. Regardless, Das Kapital was unquestionably an economic treatise, and intended to be.
Without data, it's impossible to say. My perception is that it's actually better today than it was, particularly in light of the much greater complexity of today's software products. We do see more security bugs, but I think that's due to greater scrutiny, not more bugs.
This, pretty much. The product/sales/marketing departments are bred and educated on the yearly sales cycle; software development is ultimately dictated by them.
This is true, but not in the direction you imply, I think. Left to themselves, most development and QA teams would release more often than once per year, not less. Or maybe never.
Very long development cycles are bad, because they lead to developers trying to fit too much into each release, and they lead to developers racing the release deadlines. If your product is only released once per year and you miss the deadline, your feature isn't going to launch for another full year. That provides a strong motivation to try to cram stuff in that isn't quite done.
The "natural" release cadence is driven by QA. When development cuts a release, QA starts testing it. The time it takes QA to complete testing (including time for development to fix bugs they discover) is how long development has for the next iteration. So the development cycle is naturally dependent upon the level of QA automation. I suppose QA could take longer than a year, but that seems like a dysfunctional process in nearly all cases.
Of course, not all cut and tested releases need to go to customers. But if they don't, IMO development and QA should not know which releases will go to customers.
Note that feature size and complexity varies, so whatever release cycle you use some features will be too large to fit into a single cycle. This is another problem with long release cycles, they often discourage development of features that don't fit in a cycle (note that the cadence of performance reviews also plays a role here; developers like to have concrete accomplishments to point to -- "launched feature X" is a much easier case to make than "made progress on feature X").
I think the best way to deal with this is feature control flags. Add hidden controls that turn features on or off, and default them to off while the features are under development. QA tests the default state. When a feature is complete, you change the default for the flag. If QA finds that this creates problems and the release is destined for customers, the default can be reverted, the release re-tested and launched that way. Once it's determined that the feature is solid and doesn't create problems, the flag can be removed.
The closest truce that I've seen has been the creation of LTS releases, which matches the annual or semi-annual cadence of the corporate sales/acquisition cycle
Agreed. This is the solution to the mismatch between customer needs and development cadence. And between marketing/sales goals and development cadence. And note that (like Ubuntu) there's no need to assume that one launch cadence fits all customers' needs, and indeed there's value in having more than one. But however many launch cadences are adopted, each needs to have a support commitment that lasts until after the next iteration launches (IMO, each should be supported until iteration N+2 launches, at minimum). That in turn drives a requirement for maintenance and support staff, which constrains the number of launch cadences.
What makes you think software quality is declining? I've been doing this for 30 years, and as far as I can see, everything has always been crap, with the exception of stuff that really, really had to work... and not always even then. Consider the Ariane 5 crash. And that was over 20 years ago.
I think you're erring on the side of being overly trusting. It's paranoid to be convinced that your employer is going to screw you (well, at least most employers), but it's equally wrong to be convinced that they'll be happy to go along with your plan.
If you're certain it's truly the case that they'd have to fire you to get rid of you before your chosen date and you'd have a solid lawsuit -- with a good expected payday -- if they decided to cut you loose early, then you're right. They're unlikely to screw themselves just to screw you. But you'd better get very good legal advice before doing it. I could easily see their attorney telling them that the worst case judgement you could get in a wrongful termination suit is the money that they'd have had to pay you anyway, and that they could probably negotiate that down, especially since they're in a better position to take it to court than you are, so you'd have an interest in settling.
Or they could just figure that since you're about ready to quit anyway, they can just give you all the shit jobs to do to convince you to go ahead and leave early. You'd have a choice then: hate work for your last six months, refuse to do it, in which case they could fire you for cause after documenting your failure to perform assigned tasks, or do as they wish and leave early.
All of this assumes that they actually want you gone, of course. If they don't want you to leave, if they want to use your knowledge and talents as long as possible, you're good. In fact, maybe they'll negotiate to get you to stay longer.
But unless you're really, really certain they'll treat you well, it's a good idea to be cautious. Have a backup plan.
The best advice I've seen in this thread is: When you decide you're ready to retire: Don't. Work two or three more years to give your retirement savings an extra margin of safety. Then towards the end of that time, give six months (or whatever) notice. If they choose to find a way to can you immediately, well, you were ready to retire two years earlier. If they treat you like royalty for six months and then throw you a huge retirement party, great! And you can also deal with anything in between.
I am generally curious why someone would need EVERY site to be secured by https.
Because without https, you have no assurance that the data that arrived at your web browser was the data sent by the server you wanted to reach. https is usually thought of as a data secrecy mechanism, but it's also a data integrity mechanism, and while secrecy doesn't matter everywhere, integrity does.
Note that this is true even when you don't particularly care about whether the cat video you got was the cat video you wanted, because your browser and your computer are not secure. For the same reason you don't point your browser at the dodgy corners of the Internet -- because you may just get pwned -- going to trustworthy non-https sites can screw you if there happens to be anyone malicious on the route between your computer and their server.
Moreover, if we make a habit of encrypting All The Things, we don't have to worry about snoopers seeing something that we accidentally failed to protect. Its just good network hygiene.
Slashdot Mirror
C++17 was mostly just an incremental improvement over C++14, which was an incremental improvement over C++11, and the most-anticipated feature -- Concepts -- didn't quite make it into 17. Still, the work of the committee is gradually evolving C++ into a much nicer language. Modern C++ code written according to the C++ core guidelines is simpler, clearer, safer, more maintainable -- and often more efficient.
Unfortunately, all of the old language features that are no longer recommended are still present, so the language as a whole is also becoming bigger and more complex... but if you can manage to purge all the old-style C++ from your codebase, the result is a language subset that's getting progressively easier to learn. Well, mostly. Template metaprogramming is becoming simpler and easier, but that's encouraging more and more of it, and there are still several non-obvious idioms needed to do common things. C++17 eliminates the need for a few of these, Concepts (which should, finally, land in C++20) will eliminate a lot more.
C++'s size and complexity mean that it must be used carefully. I often find myself asking people on my team to justify the clever metaprogramming constructs they create. Sure, it's cool to write a function that accepts an arbitrary number of arguments of any type, but if you only call it twice, and both times with the same number and type of args, why bother writing the complex templates that future programmers will have to laboriously parse? And if you call it many times with many different argument sets, you need to think about code bloat since the compiler has to generate another copy of the function for each argument set. So, a little discipline is essential.
But, assuming you can apply the necessary discipline, modern C++ is in a class by itself. It allows tremendously simple, expressive code that is also near-maximally efficient and obviously safe, with all memory accesses bounds-checked, and no possibility of either dangling pointers or memory leaks.
C++ is becoming awesome. I regularly spend time playing with competitors, such as Rust, and also often use dynamically-typed languages (e.g. Python, Java, C#). I've invested significant time into purely functional languages, notably Haskell. But for code that has to be efficient and precise, I keep coming back to C++ and it's getting better and better.
> transaction volume has increased beyond the design capacity.
Not if the re-designed features (SegWit, and Schnorr Signatures) were in use by everyone on the network.
FTFY.
The original design simply cannot scale. The proposed modifications would help, some. I think it's very unlikely that anything short of a complete redesign and restructuring could make it practical as a significant global currency.
But hey, we are still mostly on IPv4, there is a lot of inertia to overcome.
Yep, changing is very, very hard.
I can see a Walmart blockchain where they control 51% of the 'nodes'
They don't need that. All they need is a single server which signs all the blocks with a secret private key. Everybody with access can verify the data, but nobody else can modify it.
And each supplier could sign its own records in the chain with its private key. That would ensure that Wal-mart couldn't forge records from suppliers, and the hash chain would ensure that no one could rewrite history by removing or reordering records. It makes sense. What's not clear to me is that it's actually enough of an improvement to be worth the effort of retooling all of the existing automated systems.
Would you use a blockchain system when you needed to speed up transaction times? That's one of the claims of the article, and from everything I see, blockchain - BY DESIGN - gets slower and slower as more transactions are put into the chain.
Blockchains don't get slower as more transactions are added. What makes you think that? They don't necessarily even consume ever-growing amounts of storage, since it's always possible to agree to add some new records at the head summarizing information in the tail prior to some agreed-upon point in time, and then discard everything before that cutoff.
I'm sure you get this idea from bitcoin, but it's not accurate even for bitcoin. Bitcoin hasn't gotten slower on a per-transaction basis, it's gotten a little faster, and would be dramatically faster if it weren't for the changes made to intentionally slow down mining (note that mining is not an inherent feature of blockchains, though it makes sense for public blockchains). No, the problem with bitcoin transaction performance is that the transaction volume has increased beyond the design capacity. Transaction throughput is higher than ever, but transaction latency is through the roof because transaction demand is higher than throughput.
With that said, I really don't see how blockchains are going to help much, given that supply chains are already thoroughly automated. Right now, each party maintains a separate database and they exchange electronic documents for orders, invoices, etc. With blockchain they can create a shared ledger, but this seems like a minor win at best.
The "distributed" part is what is important, since it means that no one party can corrupt it.
That is how the current systems are setup.
It doesn't mean that Walmart can't setup an internal only "blockchain" that only runs on their intranet to track store balances.
Sure they can, but what value does it provide? A blockchain is more complicated and less efficient than a central database. If the concern is about having a single point of failure blockchains enable distributed consensus, but it's hard to see how that provides any value over a replicated database. It's hard for a well-placed employee to rewrite history with a blockchain, but that's also achievable with existing database technology, and in any case I don't see any evidence that it's a serious problem.
No, I see no value in a purely internal blockchain. There may be some value in using blockchains to establish distributed ledgers with partners (e.g. suppliers). Invoices, shipment records, receipt records, etc. could be stored in a blockchain so both parties are using a single distributed ledger rather than each maintaining its own database. Given that these sorts of processes are already thoroughly automated, though, it's not clear that a blockchain-based shared ledger would be that much better. My guess is that's the angle they're looking at, though, since it's the only thing that makes any sort of sense at all.
Better yet, call or show up at the hotel and offer cash. Works nicely for independent places -- they'll still need an ID and/or card for security, but they're willing to negotiate if you cut some of their costs (swipe, consolidator fees) out of the equation by paying cash.
If you arrive very late, offer to leave very early and to clean up after yourself so housekeeping doesn't notice the room was occupied, you can often pay a minimal fee directly to the front desk agent.
At least, that's what Jack Reacher does and everything in those books is clearly the truth.
The good news is that consumers appear to be getting the message that "smart" devices are dangerous
Meh. I doubt there's a smart thermostat on the market that doesn't have a safety temperature.
Yes, it can be big deal if you leave your thermostat off then want to turn it on remotely when the weather turns cold. If you are away for a few days and temperatures drop below freezing that will be real big deal.
Is there a smart thermostat that doesn't have a safety temperature? Nest thermostats, for example, will by default not allow the temperature to fall below 40F, even if they're turned off. And really, why would you ever set them to "off"? The whole point of having a smart thermostat is so that it will do things like figure out when no people are around and lower the temperature to a reasonable minimum to save money.
So, really, the worst case here is that you're away for a while and your house cools to 40 degrees and because your Internet connection is shut off you can't turn the temperature up until you get home. So, it's still 40 when you get home and you have to wear a jacket for an hour or two until the house gets warmed up. So, the same as what you'd have to do with a "dumb" thermostat.
I am strongly against connecting any devices (other than computers) in my home to the outside facing network
Define "computer".
I'm looking for a decent smart doorbell. I'd like one that rings when someone who doesn't live in my house approaches the door. It should have a button for backup.
And a hacker is someone who enjoys making technology do interesting things. Good luck trying to redefine common language.
For that matter, this isn't even "common" language. Researchers in the field call it AI as well, and have for decades. When necessary they distinguish between strong AI and weak AI, but most of the time it's not necessary because strong AI doesn't yet exist.
Hey Elon, you can sell your horribly overpriced snake oil to the gullible "app" crowd but it's not going to work on TRUCK people.
I'm a truck person. My vehicle is a Ford F350, w/ a 6.7L diesel. My other car is a Nissan Leaf -- all electric.
Pickup trucks are about American steel and brawn, tugging a boat and your gun rack into the woods.
Actually, it's mostly Chinese steel, but yeah, my truck tugs a boat to the lake, a camp trailer to the woods, and a gun or three everywhere. Of course, my Leaf also hauls a gun everywhere, too.
Electric simply has no place, outside of a super-niche toy for .... Whom exactly? The people who have the $ to drop on a Tesla (rich liberals and techie wimps) likely aren't driving a truck in the first place.
I deposited $1K to reserve a Model 3, which is far from a "super-niche toy". My Leaf is fairly "niche"; its niche is "running errands around town and commuting" which isn't actually such a small niche. The Model 3 isn't niche at all, it's a solid performer that meets the needs of 90% of new sedan buyers.
As for pickups, I've been talking about how awesome an electric pickup would be for years. The torque and power of electric are ideal for trucks. Big, heavy, expensive batteries fit right in to big, heavy, expensive pickup trucks -- one-tons diesels like mine start at about $60K, decently-equipped, and weigh six tons. Range while towing heavy loads will be an issue. Mine has a 37-gallon tank which gives it 600 miles of range under "normal" conditions, not because anyone needs 600 miles of range, but because when you're hauling 10,000 pounds behind it that range is cut in half. BUT, pickups also have another advantage: a bed, which is an ideal place to put an ICE generator on those occasions when you need to extend the range. Which, frankly, isn't all that often. I'd like a generator with built-in jacks that I can back under and lower in place.
I do think an F150 replacement is the wrong angle, though. Working down from the semi is the right way. Big work trucks are expensive, heavy and require lots of torque. An electric can meet the needs of a work truck, and no one will bat an eye at a $60-80K price tag. The little half ton can come later as battery prices continue falling.
my remote control I prefer
The Force you should use.
Claims of old age do not correlate with UID!
Is there an age limit for creating a /. account? I must have missed that.
But in the stories my grandfather told me I sense a great deal of exciting things. To go to town they had to marshal their team of horses and brush them out afterwards, in the cold (you could see the horse's breath).
In 1967? Was your grandfather Amish?
"Socialism is an economic system, "
Karl Marx was a philosopher.
And an economist, though a bad one who knew little of economics and allowed his philosophy to drive his economic thinking. Regardless, Das Kapital was unquestionably an economic treatise, and intended to be.
A creditor is required to take dollars for debts, but nobody is required to take dollars for goods and services.
That's what I said :-)
in the case of the Dollar at least the U.S. Government will take it for your tax payments.
And anyone else you owe will (must, by law) take it as repayment as well.
So we're both expressing opinions. Fair enough. :)
Well, except that you stated yours as fact.
Without data, it's impossible to say. My perception is that it's actually better today than it was, particularly in light of the much greater complexity of today's software products. We do see more security bugs, but I think that's due to greater scrutiny, not more bugs.
This, pretty much. The product/sales/marketing departments are bred and educated on the yearly sales cycle; software development is ultimately dictated by them.
This is true, but not in the direction you imply, I think. Left to themselves, most development and QA teams would release more often than once per year, not less. Or maybe never.
Very long development cycles are bad, because they lead to developers trying to fit too much into each release, and they lead to developers racing the release deadlines. If your product is only released once per year and you miss the deadline, your feature isn't going to launch for another full year. That provides a strong motivation to try to cram stuff in that isn't quite done.
The "natural" release cadence is driven by QA. When development cuts a release, QA starts testing it. The time it takes QA to complete testing (including time for development to fix bugs they discover) is how long development has for the next iteration. So the development cycle is naturally dependent upon the level of QA automation. I suppose QA could take longer than a year, but that seems like a dysfunctional process in nearly all cases.
Of course, not all cut and tested releases need to go to customers. But if they don't, IMO development and QA should not know which releases will go to customers.
Note that feature size and complexity varies, so whatever release cycle you use some features will be too large to fit into a single cycle. This is another problem with long release cycles, they often discourage development of features that don't fit in a cycle (note that the cadence of performance reviews also plays a role here; developers like to have concrete accomplishments to point to -- "launched feature X" is a much easier case to make than "made progress on feature X").
I think the best way to deal with this is feature control flags. Add hidden controls that turn features on or off, and default them to off while the features are under development. QA tests the default state. When a feature is complete, you change the default for the flag. If QA finds that this creates problems and the release is destined for customers, the default can be reverted, the release re-tested and launched that way. Once it's determined that the feature is solid and doesn't create problems, the flag can be removed.
The closest truce that I've seen has been the creation of LTS releases, which matches the annual or semi-annual cadence of the corporate sales/acquisition cycle
Agreed. This is the solution to the mismatch between customer needs and development cadence. And between marketing/sales goals and development cadence. And note that (like Ubuntu) there's no need to assume that one launch cadence fits all customers' needs, and indeed there's value in having more than one. But however many launch cadences are adopted, each needs to have a support commitment that lasts until after the next iteration launches (IMO, each should be supported until iteration N+2 launches, at minimum). That in turn drives a requirement for maintenance and support staff, which constrains the number of launch cadences.
Yeah, which makes no sense. Why would they want you gone?
There are a hundred possible reasons... the key is that you can't know, in the general case.
In other words, you're one of the people you describe as "It's paranoid to be convinced that your employer is going to screw you."
Nonsense. It's paranoid to be convinced of that. It's just caution to consider that it's a possibility and take some precautions.
What makes you think software quality is declining? I've been doing this for 30 years, and as far as I can see, everything has always been crap, with the exception of stuff that really, really had to work... and not always even then. Consider the Ariane 5 crash. And that was over 20 years ago.
I think you're erring on the side of being overly trusting. It's paranoid to be convinced that your employer is going to screw you (well, at least most employers), but it's equally wrong to be convinced that they'll be happy to go along with your plan.
If you're certain it's truly the case that they'd have to fire you to get rid of you before your chosen date and you'd have a solid lawsuit -- with a good expected payday -- if they decided to cut you loose early, then you're right. They're unlikely to screw themselves just to screw you. But you'd better get very good legal advice before doing it. I could easily see their attorney telling them that the worst case judgement you could get in a wrongful termination suit is the money that they'd have had to pay you anyway, and that they could probably negotiate that down, especially since they're in a better position to take it to court than you are, so you'd have an interest in settling.
Or they could just figure that since you're about ready to quit anyway, they can just give you all the shit jobs to do to convince you to go ahead and leave early. You'd have a choice then: hate work for your last six months, refuse to do it, in which case they could fire you for cause after documenting your failure to perform assigned tasks, or do as they wish and leave early.
All of this assumes that they actually want you gone, of course. If they don't want you to leave, if they want to use your knowledge and talents as long as possible, you're good. In fact, maybe they'll negotiate to get you to stay longer.
But unless you're really, really certain they'll treat you well, it's a good idea to be cautious. Have a backup plan.
The best advice I've seen in this thread is: When you decide you're ready to retire: Don't. Work two or three more years to give your retirement savings an extra margin of safety. Then towards the end of that time, give six months (or whatever) notice. If they choose to find a way to can you immediately, well, you were ready to retire two years earlier. If they treat you like royalty for six months and then throw you a huge retirement party, great! And you can also deal with anything in between.
I am generally curious why someone would need EVERY site to be secured by https.
Because without https, you have no assurance that the data that arrived at your web browser was the data sent by the server you wanted to reach. https is usually thought of as a data secrecy mechanism, but it's also a data integrity mechanism, and while secrecy doesn't matter everywhere, integrity does.
Note that this is true even when you don't particularly care about whether the cat video you got was the cat video you wanted, because your browser and your computer are not secure. For the same reason you don't point your browser at the dodgy corners of the Internet -- because you may just get pwned -- going to trustworthy non-https sites can screw you if there happens to be anyone malicious on the route between your computer and their server.
Moreover, if we make a habit of encrypting All The Things, we don't have to worry about snoopers seeing something that we accidentally failed to protect. Its just good network hygiene.