Another option is to use the read command to store it in an environment variable, never having it on the CLI in the first place. This lets history still show you everything you did, but without the password and such in it.
You jest, but on this front, Google has gone through so many trials and changed their minds to try a new approach, either because it failed to catch on or they didn't do it in a way that enables enough profit.
People use Android, Maps, Google search, and email. They use youtube, but google paid for that, unable to organically come up with something. Google Plus, Wave, Allo, and tons of other things have not achieved success, areas that Google desperately wants to be a part of.
Strange to say email addresses should be considered antiquated and turn around and say that phone numbers shouldn't be.
email addresses continue to be a universally known thing and are popularly used.
The problem is that in practice, email is very permissive and as such you can email from your provider to a provider they've never heard of (with unfortunate security implications that have not been overcome). In XMPP, your chat server administrator has to explicitly do something to establish a relationship with every org that you might want to talk to. As a federated technology, it falls short.
Certain modern norms tha tbenefit the enduser are a result of happening at just the right time.
The network companies of the time could not keep up with the internet, and as such there were no players to prevent email from settling into the unassailable role it had gotten. It's possible that if AOL had played things a tad bit differently, we'd all be using AOL mail instead and email would be like XMPP, this idealistic concept that no one uses because it can't reach most people. None of the business folk at the time that had the resources was able to foresee a strategy to 'own' that. In this century however, federated standards have generally failed to succeed, as the stakeholders now have a handle on how to prevent that from happening again.
Same with drm-free music. When wired internet became feasible to transfer music, but maybe not quite stream it as well as music players that couldn't realistically connect to the internet, attempts at DRM failed so badly they had to give up on the concept. By the time video became feasible, so to had network connectivity evolved to the point where any video playback device could pretty much have some network access at all times, or maybe it was the move away from hardware device provided interface towards 'apps' to consume a video content providers product.
If you strike and get some fundamental truth about technology established, it's hard to get rid of, but the companies are *all* over messaging and won't stand for it.
The problem is that none of those companies want a federated standard, *and* at least Google, Facebook, and Apple all have the resources to out-compete any standard.
Otherwirse, XMPP (which already exists) would be more viable. None of the services want to endorse a system that allows communicating with users of their platform without first becoming a user of their platform yourself. Sadly, an alternative approach is unlikely to be a sound business plan, and the marketing dollars and such that come with a business plan are currently more important to adoption than any consideration like federated capability.
While I agree with the sentiment, in practice it's not so straightforward.
The way we quantify wealth as dollars is not perfect and the value of a dollar is subjective. For example a brand new ferrari costs about as much as 20 Ford fiestas. However, if you took the resources and manhours that made that one ferrari, they could not produce 20 ford fiestas. Moving up the price scale magical things happen and the dollars mean less in real terms. You can't take the resources that make high priced items and magically transform them into food.
Beyond the dollar, we also have things where wealth is measured in capital and stock and such. For example, Zuckerberg has $24 billion of Facebook stock. Say he decides all of a sudden, he wants to cash out. Facebook stock would tank as he would try to sell it, because there isn't *really* $24 billion worth of purchasers, and further *Zuckerberg* selling would cause the stock to crash due to perception.
There's certainly things unfair and wrong, but the property of the affluent will never be able to magically become food for everyone.
While that is true for some businesses, for many others it's like big data again. A capable technology, but still needs some vague hint of vision in terms of how it relates to a given business. I'd say most companies struggling to hire AI lack vision as to how it could relate, and hope that throwing some money at the buzzword will work instead.
This is more a hype cycle than a technology cycle. This is going to be good for some companies that try something they didn't realize they had ideas on how to apply such technology, and it's going to cause a lot of confusion and churn in probably most companies that feel a need to try something, anything related to AI.
I think you may be fairly unique, I've never heard anyone else say they do this or heard any human give humans directions in terms of estimated time..
As others mentioned, while you could extrapolate a guess, particularly at 1/2 mile away the likelihood of an unpredictable momentary traffic condition completely ruining that guess is very high.
I personally glance at the map to get a sense for whether or not it's the very next available road in that direction, or if it's the second or third intersection. This also involves some fudging, as I have to make a judgement call about whether the intersection I see is a road that would be on the map or some minor private road-looking thing. This can cut both ways, an unassuming dirt road that I would have guessed would not be mapped would be mapped as well as a nice looking road turning out to be some high end house's driveway. So I'm more looking at the rough general shape than counting or anything I suppose.
While the data is lacking, my guess is that there are a couple of key factors: -A *large* windfall is more likely to make people lose any sense of perspective and feel like they got money forever at some level in their minds (even if they consciously know it's not the case, the way they *feel* may influence them a lot). Small benefits are more likely to be used with care. -The circumstances of the person being aided. For example, I have known folks who were so poor they couldn't afford to regularly eat. They were very pragmatic about any income and treated it with a great deal of care. They took their situation seriously enough that they were more productive when they weren't paralyzed by worrying about basics. On the other hand, I have also known people that had no income, but basically grew up with enough assistance to at least have a roof over their heads and food in their stomachs. Those tended to waste any extra income that came in on whatever they felt like, and never applied themselves.
Searching the internet for 'alkaline voltage curve' will lead to a variety of graphs. I will say it looks like generally things take a sharp turn at about 1V, rather than 0.9V.
I also had a voltmeter that shows 'bad', 'questionable', and 'good' instead of voltages. Below 1.0V, that's 'bad', 1.0-1.1V is 'questionable', 1.1V lands in 'God'.
Plugging into a relatively recent device, that devices batter meter declares it as 'full', suggesting that one was specifically designed with the thought of 1.2V being great. I put fully charged LSD NiMH in a 15 year old camera, and it declares the battery as 1/3 'bars' (with 'blinknig empty box' being the next level).
I will also attest that I've not encountered a single device that would not operate at 1.2V per battery. I know that for devices that take battery *or* DC input, the DC input almost always is 1.5V * the number of batteries, however they clearly continue to function at lower battery voltages.
I would wager there are wasteful things out there that can't handle 1.2V, but such a device runs the risk of being seen as a 'battery eater' since such devices would be nearly halving the usable capacity of the batteries you give it. If you did have such a device, it would be mandating use of Lithium AA batteries, but I haven't personally seen devices with that requirement, though I presume they exist.
I agree with the sentiment, but I think we are in the minority. Most people seem to like plugging in their phone charge cord into whatever it is and going, and they aren't even thinking about that device 5 years down the line.
I would love more direct use of standard size Li-ion cells, compared to custom packaging of Li-ion.
Oh, I neglected to mention that while Alkaline voltage drops with capacity, NiMH has a pretty flat voltage relatively speaking. It stays right around 1.2V for most of it's capacity, then drops all of a sudden as it nears drained.
This is about the non-rechargeable alkaline batteries, which generally manufacturers are moving away from needing in favor of Li-ion batteries, they are more convenient and now more affordable than they used to be. If you release using alkaline batteries against a competitor with baked in li-on, you'll probably lose.
For the market that still uses AA, AAA, C, and D cell sorts of batteries, well low self-discharge NiMH is very appealing now. Shelf-stable batteries that can be recharged without concern about 'memory' are much more practical than batteries of the past.
So volumes dip and the vendors adjust their output and pricing to have the smaller customer base sustain their business.
If you need more than 1.2V out of your alkaline battery, you will chew threw batteries pretty quickly. A typical discharge curve has about 40% capacity left when the alkaline hits 1.2V. Generally you don't consider an alkaline depleted until it's at 0.9V.
If you design for 1.5V, then the batteries will become useless even though you have more than 95% of your capacity remaining.
Alkaline voltage drops proportional to charge pretty dramatically. It would be *nicer* if the voltage on NiMH was higher, but anything that demanded more than 1.2V out of alkaline batteries was pretty crappy.
Interestingly enough, it's more like a 'master of all trades'. The reality is that while there are some unique needs for a phone versus a desktop versus embedded networking equipment versus a server, they also have a lot in common (the general concept of organizing codes into 'processes' and 'threads'). Also, we are deeply in a world where purpose-built hardware has to a large extent given way to generics (nowadays it's more likely your cell phone signal is handled by SDR on servers in the tower than a hardware raidio).
From various people I've talked to, academically it seems that by all rights the kernel *should* have to be carved up to be productive in managing the project. In actual practice however, it seems to work better than one would think it should work.
I don't think it would make custom kernels easier, but it could greatly alleviate the complexity associated with installing third party drivers. On the other hand this might be viewed as a feature. Because out-of-tree drivers were so challenging to do, almost all the significant companies ultimately relented and enabled open source drivers for their equipment rather than fight the nightmare of supporting binary kernel modules. If Linux from the get go had very long lived and very stable driver ABI, we wouldn't have nearly as ubiquitous open source driver support as we do.
Certainly in some software and especially desktop software, the efficiency of communication between parts of the kernel is down in the noise. However there continue to be exceedingly latency sensitive scenarios where the developers have done the hard work to minimize every last little hit to performance. Of course this is taking the claim that micro kernel necessarily means a compromise on performnace at face value, which is not necessarily true.
The Linux kernel is one of those things that seem to work better in practice than in theory in terms of reliability and security. Nothing is perfect, but their track record isn't too shabby and I'm not sure if a microkernel would fare better on the security half of things. Now one can rightfully argue that as a 'driver model' it's a very hostile environment for third-party modules and makes it impossible to have a distinct cadence for each component. For the former that bites people frequently, but the latter, in practice, works out better than it has any right to.
Versions are a way of conveying information. For simplistic and/or obscure projects, adherence to general rules of thumb help people know how to interact with your software.
For the kernel, well, they are special and for them torturing themselves over whether a particular interval has something that *means* x or y or z changes in an x.y.z version is a waste of time. For them, the direct technical stakeholders have a much more nuanced understanding of how it develops than any version number could possibly convey. For the lay man, there is no kernel version, there is 'RedHat 7' or 'Ubuntu 17.10', the kernel version is some obscure detail they don't bother with.
He simply meant that for the linux kernel, the version numbers after 2.6 are meaningless except to say x is newer than y. It's just how they chose to do it. He is not making some grand statement about version numbers in general, it's just the particular approach they do for the kernel.
The kernel is well enough known, does a lot of different things, and wrapped by other organizations that it can be one of the 'special snowflakes' and not really be a big part of the whole 'versioning' philosophy.
The problem for the kernel is it has exceedingly broad scope and as such has hit difficulties with the 'major functionality' criteria.
Some major networknig addition that only matters for telcos lands in a kernel and that drives a bump, even though 90% of the users don't even use it? There a new DM module for a nice enterprise storage that does nothing for a phone user?
When they did do the major functions are held back dance, some 'major things' that were quick got held up for years waiting for other 'major things' that were not so quick.
Think there's a difference in interupreting the sense of 'should'.
He is saying 'should' as in 'I expect it should be meaningless' as in 'As it stands, I don't see a forseeably different reason to bump the version number, but it's going to happen anyway to keep the numbers small'.
It all boils down to there originally being meaning, and the kernel suffering greatly as a result of how they went (spending years of drift from stability that would be herculean to overcome as it sat in unstable.
Then they decided that they had no 'casual' users at all, and so they could treat every little release as a combination fix/feature release, and the cadence of efforts would not tangle each other up. The 'casual' users are sheltered from the details by RedHat, Debian, SuSE, or Ubuntu, all of which do work to understand the real nature of a kernel and do backports as appropriate.
My projects don't require specific pythons, works with several to avoid needing a python runtime bundled.
Will have to run more thorough python 3 tests, as prior to RHEL8, the only baked in versions were 2.x. Would have been nice to have both 2 and 3 available as first-class at least for one generation of the distro.
RHEL is also the reason I still have to support Python 2.6, due to the enduring popularity of RHEL6.
It's simple enough: the corporate strategy is hiring more in cheaper geographies. This could be fine if: -The cheaper geography provided the *whole* dev team, and not just part of it (navigating 12-hour time zone differences is a nightmare) -They actually picked solid developers in the cheaper geos, instead taking them at face value because they have no hope of vetting candidates, and unable to recognize "too good to be true" because they are clouded by the "cheap geo" thing (When a good candidate actually comes online, I can be sure they will be moving on to another company in their country for more money within the month).
The more developers is an olive branch to say "sorry you can't have a local team, but we can give you *more* developers to make up for the inconvenience", never acknowledging that in some cases, no quantity will make up for lack of quality.
Slashdot Mirror
Another option is to use the read command to store it in an environment variable, never having it on the CLI in the first place. This lets history still show you everything you did, but without the password and such in it.
Actually, not all bash setups are configured to ignore things that start with spaces.
$ echo $HISTCONTROL
ignoredups
ignorespaces has confused so many people that I think a lot of distributions have stopped putting that in HISTCONTROL.
You jest, but on this front, Google has gone through so many trials and changed their minds to try a new approach, either because it failed to catch on or they didn't do it in a way that enables enough profit.
People use Android, Maps, Google search, and email. They use youtube, but google paid for that, unable to organically come up with something. Google Plus, Wave, Allo, and tons of other things have not achieved success, areas that Google desperately wants to be a part of.
Strange to say email addresses should be considered antiquated and turn around and say that phone numbers shouldn't be.
email addresses continue to be a universally known thing and are popularly used.
The problem is that in practice, email is very permissive and as such you can email from your provider to a provider they've never heard of (with unfortunate security implications that have not been overcome). In XMPP, your chat server administrator has to explicitly do something to establish a relationship with every org that you might want to talk to. As a federated technology, it falls short.
Certain modern norms tha tbenefit the enduser are a result of happening at just the right time.
The network companies of the time could not keep up with the internet, and as such there were no players to prevent email from settling into the unassailable role it had gotten. It's possible that if AOL had played things a tad bit differently, we'd all be using AOL mail instead and email would be like XMPP, this idealistic concept that no one uses because it can't reach most people. None of the business folk at the time that had the resources was able to foresee a strategy to 'own' that. In this century however, federated standards have generally failed to succeed, as the stakeholders now have a handle on how to prevent that from happening again.
Same with drm-free music. When wired internet became feasible to transfer music, but maybe not quite stream it as well as music players that couldn't realistically connect to the internet, attempts at DRM failed so badly they had to give up on the concept. By the time video became feasible, so to had network connectivity evolved to the point where any video playback device could pretty much have some network access at all times, or maybe it was the move away from hardware device provided interface towards 'apps' to consume a video content providers product.
If you strike and get some fundamental truth about technology established, it's hard to get rid of, but the companies are *all* over messaging and won't stand for it.
The problem is that none of those companies want a federated standard, *and* at least Google, Facebook, and Apple all have the resources to out-compete any standard.
Otherwirse, XMPP (which already exists) would be more viable. None of the services want to endorse a system that allows communicating with users of their platform without first becoming a user of their platform yourself. Sadly, an alternative approach is unlikely to be a sound business plan, and the marketing dollars and such that come with a business plan are currently more important to adoption than any consideration like federated capability.
While I agree with the sentiment, in practice it's not so straightforward.
The way we quantify wealth as dollars is not perfect and the value of a dollar is subjective. For example a brand new ferrari costs about as much as 20 Ford fiestas. However, if you took the resources and manhours that made that one ferrari, they could not produce 20 ford fiestas. Moving up the price scale magical things happen and the dollars mean less in real terms. You can't take the resources that make high priced items and magically transform them into food.
Beyond the dollar, we also have things where wealth is measured in capital and stock and such. For example, Zuckerberg has $24 billion of Facebook stock. Say he decides all of a sudden, he wants to cash out. Facebook stock would tank as he would try to sell it, because there isn't *really* $24 billion worth of purchasers, and further *Zuckerberg* selling would cause the stock to crash due to perception.
There's certainly things unfair and wrong, but the property of the affluent will never be able to magically become food for everyone.
While that is true for some businesses, for many others it's like big data again. A capable technology, but still needs some vague hint of vision in terms of how it relates to a given business. I'd say most companies struggling to hire AI lack vision as to how it could relate, and hope that throwing some money at the buzzword will work instead.
This is more a hype cycle than a technology cycle. This is going to be good for some companies that try something they didn't realize they had ideas on how to apply such technology, and it's going to cause a lot of confusion and churn in probably most companies that feel a need to try something, anything related to AI.
If you see fish swimming by your window, then you've gone too far.
I think you may be fairly unique, I've never heard anyone else say they do this or heard any human give humans directions in terms of estimated time..
As others mentioned, while you could extrapolate a guess, particularly at 1/2 mile away the likelihood of an unpredictable momentary traffic condition completely ruining that guess is very high.
I personally glance at the map to get a sense for whether or not it's the very next available road in that direction, or if it's the second or third intersection. This also involves some fudging, as I have to make a judgement call about whether the intersection I see is a road that would be on the map or some minor private road-looking thing. This can cut both ways, an unassuming dirt road that I would have guessed would not be mapped would be mapped as well as a nice looking road turning out to be some high end house's driveway. So I'm more looking at the rough general shape than counting or anything I suppose.
While the data is lacking, my guess is that there are a couple of key factors:
-A *large* windfall is more likely to make people lose any sense of perspective and feel like they got money forever at some level in their minds (even if they consciously know it's not the case, the way they *feel* may influence them a lot). Small benefits are more likely to be used with care.
-The circumstances of the person being aided. For example, I have known folks who were so poor they couldn't afford to regularly eat. They were very pragmatic about any income and treated it with a great deal of care. They took their situation seriously enough that they were more productive when they weren't paralyzed by worrying about basics. On the other hand, I have also known people that had no income, but basically grew up with enough assistance to at least have a roof over their heads and food in their stomachs. Those tended to waste any extra income that came in on whatever they felt like, and never applied themselves.
you can go hunter2 my hunter2-ing hunter2
Even the name is relevant.
Searching the internet for 'alkaline voltage curve' will lead to a variety of graphs. I will say it looks like generally things take a sharp turn at about 1V, rather than 0.9V.
I also had a voltmeter that shows 'bad', 'questionable', and 'good' instead of voltages. Below 1.0V, that's 'bad', 1.0-1.1V is 'questionable', 1.1V lands in 'God'.
Plugging into a relatively recent device, that devices batter meter declares it as 'full', suggesting that one was specifically designed with the thought of 1.2V being great. I put fully charged LSD NiMH in a 15 year old camera, and it declares the battery as 1/3 'bars' (with 'blinknig empty box' being the next level).
I will also attest that I've not encountered a single device that would not operate at 1.2V per battery. I know that for devices that take battery *or* DC input, the DC input almost always is 1.5V * the number of batteries, however they clearly continue to function at lower battery voltages.
I would wager there are wasteful things out there that can't handle 1.2V, but such a device runs the risk of being seen as a 'battery eater' since such devices would be nearly halving the usable capacity of the batteries you give it. If you did have such a device, it would be mandating use of Lithium AA batteries, but I haven't personally seen devices with that requirement, though I presume they exist.
I agree with the sentiment, but I think we are in the minority. Most people seem to like plugging in their phone charge cord into whatever it is and going, and they aren't even thinking about that device 5 years down the line.
I would love more direct use of standard size Li-ion cells, compared to custom packaging of Li-ion.
Oh, I neglected to mention that while Alkaline voltage drops with capacity, NiMH has a pretty flat voltage relatively speaking. It stays right around 1.2V for most of it's capacity, then drops all of a sudden as it nears drained.
This is about the non-rechargeable alkaline batteries, which generally manufacturers are moving away from needing in favor of Li-ion batteries, they are more convenient and now more affordable than they used to be. If you release using alkaline batteries against a competitor with baked in li-on, you'll probably lose.
For the market that still uses AA, AAA, C, and D cell sorts of batteries, well low self-discharge NiMH is very appealing now. Shelf-stable batteries that can be recharged without concern about 'memory' are much more practical than batteries of the past.
So volumes dip and the vendors adjust their output and pricing to have the smaller customer base sustain their business.
If you need more than 1.2V out of your alkaline battery, you will chew threw batteries pretty quickly. A typical discharge curve has about 40% capacity left when the alkaline hits 1.2V. Generally you don't consider an alkaline depleted until it's at 0.9V.
If you design for 1.5V, then the batteries will become useless even though you have more than 95% of your capacity remaining.
Alkaline voltage drops proportional to charge pretty dramatically. It would be *nicer* if the voltage on NiMH was higher, but anything that demanded more than 1.2V out of alkaline batteries was pretty crappy.
Interestingly enough, it's more like a 'master of all trades'. The reality is that while there are some unique needs for a phone versus a desktop versus embedded networking equipment versus a server, they also have a lot in common (the general concept of organizing codes into 'processes' and 'threads'). Also, we are deeply in a world where purpose-built hardware has to a large extent given way to generics (nowadays it's more likely your cell phone signal is handled by SDR on servers in the tower than a hardware raidio).
From various people I've talked to, academically it seems that by all rights the kernel *should* have to be carved up to be productive in managing the project. In actual practice however, it seems to work better than one would think it should work.
I don't think it would make custom kernels easier, but it could greatly alleviate the complexity associated with installing third party drivers. On the other hand this might be viewed as a feature. Because out-of-tree drivers were so challenging to do, almost all the significant companies ultimately relented and enabled open source drivers for their equipment rather than fight the nightmare of supporting binary kernel modules. If Linux from the get go had very long lived and very stable driver ABI, we wouldn't have nearly as ubiquitous open source driver support as we do.
Certainly in some software and especially desktop software, the efficiency of communication between parts of the kernel is down in the noise. However there continue to be exceedingly latency sensitive scenarios where the developers have done the hard work to minimize every last little hit to performance. Of course this is taking the claim that micro kernel necessarily means a compromise on performnace at face value, which is not necessarily true.
The Linux kernel is one of those things that seem to work better in practice than in theory in terms of reliability and security. Nothing is perfect, but their track record isn't too shabby and I'm not sure if a microkernel would fare better on the security half of things. Now one can rightfully argue that as a 'driver model' it's a very hostile environment for third-party modules and makes it impossible to have a distinct cadence for each component. For the former that bites people frequently, but the latter, in practice, works out better than it has any right to.
Versions are a way of conveying information. For simplistic and/or obscure projects, adherence to general rules of thumb help people know how to interact with your software.
For the kernel, well, they are special and for them torturing themselves over whether a particular interval has something that *means* x or y or z changes in an x.y.z version is a waste of time. For them, the direct technical stakeholders have a much more nuanced understanding of how it develops than any version number could possibly convey. For the lay man, there is no kernel version, there is 'RedHat 7' or 'Ubuntu 17.10', the kernel version is some obscure detail they don't bother with.
He simply meant that for the linux kernel, the version numbers after 2.6 are meaningless except to say x is newer than y. It's just how they chose to do it. He is not making some grand statement about version numbers in general, it's just the particular approach they do for the kernel.
The kernel is well enough known, does a lot of different things, and wrapped by other organizations that it can be one of the 'special snowflakes' and not really be a big part of the whole 'versioning' philosophy.
The problem for the kernel is it has exceedingly broad scope and as such has hit difficulties with the 'major functionality' criteria.
Some major networknig addition that only matters for telcos lands in a kernel and that drives a bump, even though 90% of the users don't even use it? There a new DM module for a nice enterprise storage that does nothing for a phone user?
When they did do the major functions are held back dance, some 'major things' that were quick got held up for years waiting for other 'major things' that were not so quick.
Think there's a difference in interupreting the sense of 'should'.
He is saying 'should' as in 'I expect it should be meaningless' as in 'As it stands, I don't see a forseeably different reason to bump the version number, but it's going to happen anyway to keep the numbers small'.
It all boils down to there originally being meaning, and the kernel suffering greatly as a result of how they went (spending years of drift from stability that would be herculean to overcome as it sat in unstable.
Then they decided that they had no 'casual' users at all, and so they could treat every little release as a combination fix/feature release, and the cadence of efforts would not tangle each other up. The 'casual' users are sheltered from the details by RedHat, Debian, SuSE, or Ubuntu, all of which do work to understand the real nature of a kernel and do backports as appropriate.
My projects don't require specific pythons, works with several to avoid needing a python runtime bundled.
Will have to run more thorough python 3 tests, as prior to RHEL8, the only baked in versions were 2.x. Would have been nice to have both 2 and 3 available as first-class at least for one generation of the distro.
RHEL is also the reason I still have to support Python 2.6, due to the enduring popularity of RHEL6.
It's simple enough: the corporate strategy is hiring more in cheaper geographies. This could be fine if:
-The cheaper geography provided the *whole* dev team, and not just part of it (navigating 12-hour time zone differences is a nightmare)
-They actually picked solid developers in the cheaper geos, instead taking them at face value because they have no hope of vetting candidates, and unable to recognize "too good to be true" because they are clouded by the "cheap geo" thing (When a good candidate actually comes online, I can be sure they will be moving on to another company in their country for more money within the month).
The more developers is an olive branch to say "sorry you can't have a local team, but we can give you *more* developers to make up for the inconvenience", never acknowledging that in some cases, no quantity will make up for lack of quality.