His point was, that there is no point in optimizing the code that barely takes any resources to begin with.
Actually his point is usually applied to a concept of "hot path" where, regardless of how many resources a peice of code "takes", what matters is how often that peice of code is run. The problem with doing this is that programs and their usage patterns change and evolve over time. What was not a "hot path" yesterday can become one due to changes outside the program itself -- e.g. suddenly all the packets it receives have an option set that was only set on 1% of packets when the code was initially profiled.
So you end up with code that can break into being slow, rather than being obviously broken. This increases your workload supporting the program post-release. You have to replicate what customers are doing (good luck) and re-profile while under that particular load to find the new hot paths. So while scripting languages are hailed for ease of development, ease of maintenance in a high performance environment is another matter entirely. If you optimize more things to start out with, you don't end up with this explosion of performance test cases to check.
Not all latency-sensitive inputs are reactions. In fact most are not pure reaction -- you see a temporal pattern happening on the screen and you have to estimate based on past experience with the same pattern when to press the key. In other words you have warning. Having a lot of extra latency in the input system can make this feel less natural.
Hrm. So let me get this straight. If you spend a year inventing something, and then do some backslapping in restaurants with people for nine years, you're supposed to make money of royalties, licensing, and perhaps celebrity, hand over fist for decades, but if you work for decades, you're supposed to just maybe keep pace with inflation.
Yup. I think that captures what's wrong with American business mentality and perverse motivations/drivers in the capitalist system pretty much exactly.
And if you really knows what you are doing, is better to do your own specialized code than using a generic-framework one.
I'm sympathetic to this argument. I even use it frequently. But one thing to note is that using frameworks would not be quite so utterly inefficient if the development community could make their mind up which ones are worth using instead of several apps all loading their own flavor-of-the-month, each choading on your RAM instead of sharing between apps
One thing I wish TFA had addressed is the prospects for much larger RAMs in mobile devices. It addresses the CPU speed prospects, but then goes on to point out memory as the bigger problem, and never touches on what is likely to occur in that area.
You spend the same amount of money on screen and UI hardware, and then shave a sliver of the total system cost off by skimping on CPU and RAM, then spend much more than what you saved on beefed up network infrastructure to accomodate the larger payload. Thats what.
Thin clients only make sense as a way to salvage older thick clients when you just happen to have next to no money to spend, and already for some reason have an overpowered network and server infrastructure. Or if your user base is so supid that they cannot be trusted not to throw them in the dishwasher.
This. Looking at existing tests is also very educational. They often show where the codebase was confusing enough to cause recurring regressions.
The other place to make very, very sure to read is the repository commit logs, if you have them. They'll tell you a lot about why the code is in its current state, and will often show you where refactors have been left half-complete.
Anyways, it makes sense that air quality is worse in areas with less trees leading to higher rates of lung disease
Given the plumes of VOCs trees emit, no that makes no sense at all. Now, having a bunch of dead decaying trees lying around after being killed by an infestation, THAT impacting air quality would seem to make sense.
I work in an educational environment where we've done BYOD since before the acronym got coined. Even in this very permissive environment, we still insist that certain OSes pass a basic NAC sanity scan to reduce the disease vectors inside the firewall. (It's all easily circumenventable, but less trouble to circumvent than to comply.) This brings down the infection rate to a level manageable by the help desk and IT staff.
We do have IP and PII concerns. We address them organizationally by clearly defining the boundaries where work with certain types of information may occur through user education. This generally does not constrain users to the point of hurting innovation -- interacting with this type of data is only a small part of most jobs here. Companies that fixate on technical solutions to problems that can be solved organizationally are only hurting themselves.
So the end result is people can BYOD, but they are patched up (because bypassing the NAC is 30 minutes work versus 5 minutes complying) can't be running open servers on them (as the firewall won't let inbound connections in) and are not using them to process the latest payroll, because they mostly cannot get to that data due to host/firewall policy, and where they can, they know they shouldn't do that.
All that being said, a larger voltage with a low current, when sufficiently protected with a power negotiation protocol like that used in PoE, is going to be safer than a high current LV source. A sufficiently low voltage source might not be able to electrocute you, but it's pretty damn good at starting fires compared to a HV source with an effective input resistance.
Pretty much the same reason I'm still here... I've managed to succeed enough to be comfortable, do so without pillaging, and work in an area that has potential to deliver productive change to the country. So I think I'll just keep that up.
If you want to make your life better, that's on you: it won't be handed to you.
Absolutely on target. The very first step to doing this, of course, is realizing theat "the system is rigged and the man is keeping you down", and the second is figuring out how to do something about that.
OR, you could buy into the idea that if you just stick your neck out far enough, some Donald Trump's next pyramid scheme won't milk you from what little cash or manpower you have at your disposal and instead will make you magnificently wealthy. But I would not recommend that.
They were testing long-ish term exposure of the older mouse body to blood constantly filtered through the younger mouse's system. Doing that is apparently cheaper and more humane than harvesting and transfusing 24x7.
Any treatment they (meaning any sanely regulated or ethical medical establishment) develop from this won't expose the donor, that would violate a lot of laws, policies, codes and consciences.
While carrots and APAP are both in common use by the populance, carrots do not provide instant relief from sudden onset of pain. When you burn yourself with hot grits, you can either stand there and think "you know, if I had eaten carrots instead then maybe I'd be in a better mood about burning myself with hot grits" Or you can take a pain reliever.
So we need pain relievers, not just carrots.
Carrots also do not do another thing: kill you if you eat too much, with "too much" being something you could get down in a single swallow, or gradually take over the course of a day without any stomach cramps to let you know you are doing something fatal. Carrots don't kill people or cause intractable medical expenses when used improperly, barring some rather deviant practices (sometimes involving hot grits as well).
As such, it's very important to understand the reasons why a person might use these substances, so that we can educate the public about which substances to use under what conditions. If APAP can help a person avoid using a more damaging or addictive psycoactive phrametceutical, but has to be used with care, we need to know that.
Anyway, scientists study diet just fine. They are even finally getting around to studying intestinal flora in better detail. Of course there is a funding bias when big pharma levels of money are involved, but that's just capitalism and greed doing its usual damage when we fail to set good boundaries for it.
This. Anxiety and panic aren't always beneficial and they don't always end on their own. Sometimes they run away with themselves in completely unproductive directions, and will cause you to do some pretty crazy and potentially self-damaging things. Since your brain has effectively been disabled, you can't just self-discipline your way out of them either.
They can get so bad that you have to go the ER and have them break the feedback loop with a Lorazepam or whatnot.
Not to mention the actual physical toll that cronic anxiety can have on the health of the rest of your body (from extreme stress levels) is damaging to your longterm health.
Except it will leave you a walking dead man for a couple of days while your body tries to live without a functional liver, and doctors cannot do a thing about it. So that probably would be an even worse existential crisis.
The fact Javascript has a curly braces syntax doesn't mean it can't be a functional programming language.
Actually the thing that makes a functional language a functional language has nothing to do with curly braces. The defining principle of functional languages is that you have to have special hacks built into the language that technically violate it's functionality in order to make it do anything -- eh -- functional -- due to the fact that side effects are the only useful way to get anything done.
I'm also a bit concerned about this "netifd" creature. I'll have to figure out how to wedge it onto something I'm not using in production in order to play with it, but it seems at first blush to be removing a lot of scripting capabilities surrounding the network event system, which I use a lot, in ways that are not expressable/supported in/etc/config/network. It also takes the configuration further away from matching what happens on a normal linux host, which will create more of a dichotomy to code on both sides of.
Speaking as someone currently considering buying slightly behind the curve, I was all set to jump on an Intel-based fanless system because of the TDP figures. However, with the PowerVR versions of the Intel GPU c**k-blocking linux graphics, and with AMD finally open-sourcing UVD, I'm now back to considering a Brazos. Less choices for fanless pre-built systems, though. May have to skip on the pay-a-younger-geek-because-I-dont-enjoy-playing-legos-anymore part.
So no, for some markets, Intel has not yet realized the advantage that their IC processes should technically give them, and to the point of TFA, if they do not combine that advantage with architectural improvements, there will be ways for AMD to stay in this market for some time to come.
You would not think anyone would be so dumb to set these up but some may be legacy, or put in place by a local hero sysadmin.
A lot of these are spare aux or console ports on Cisco routers. The actual syntax used to set one up is a bit contorted, so it's possible for someone inexperienced who is following crib notes to think they are just enabling access to the serial port from the router commandline when in fact they are also enabling an alternate telnet/ssh port.
Also a few of the newer platforms coming out from Cisco include the ability to run a linux server on the second core ("embedded service module") and the default configuration has a rather permissive "transport output" statement on the emulated serial port joining the IOS to the ESM.
LOM has mitigated the need for most of these setups, but there is still gear where the only reliable rescue console is on the serial port.
Slashdot Mirror
This is in the spirit of that post, which identified the problem as RAM wastage. By posting it again, more RAM gets consumed for the same object.
His point was, that there is no point in optimizing the code that barely takes any resources to begin with.
Actually his point is usually applied to a concept of "hot path" where, regardless of how many resources a peice of code "takes", what matters is how often that peice of code is run. The problem with doing this is that programs and their usage patterns change and evolve over time. What was not a "hot path" yesterday can become one due to changes outside the program itself -- e.g. suddenly all the packets it receives have an option set that was only set on 1% of packets when the code was initially profiled.
So you end up with code that can break into being slow, rather than being obviously broken. This increases your workload supporting the program post-release. You have to replicate what customers are doing (good luck) and re-profile while under that particular load to find the new hot paths. So while scripting languages are hailed for ease of development, ease of maintenance in a high performance environment is another matter entirely. If you optimize more things to start out with, you don't end up with this explosion of performance test cases to check.
Not all latency-sensitive inputs are reactions. In fact most are not pure reaction -- you see a temporal pattern happening on the screen and you have to estimate based on past experience with the same pattern when to press the key. In other words you have warning. Having a lot of extra latency in the input system can make this feel less natural.
Hrm. So let me get this straight. If you spend a year inventing something, and then do some backslapping in restaurants with people for nine years, you're supposed to make money of royalties, licensing, and perhaps celebrity, hand over fist for decades, but if you work for decades, you're supposed to just maybe keep pace with inflation.
Yup. I think that captures what's wrong with American business mentality and perverse motivations/drivers in the capitalist system pretty much exactly.
And if you really knows what you are doing, is better to do your own specialized code than using a generic-framework one.
I'm sympathetic to this argument. I even use it frequently. But one thing to note is that using frameworks would not be quite so utterly inefficient if the development community could make their mind up which ones are worth using instead of several apps all loading their own flavor-of-the-month, each choading on your RAM instead of sharing between apps
One thing I wish TFA had addressed is the prospects for much larger RAMs in mobile devices. It addresses the CPU speed prospects, but then goes on to point out memory as the bigger problem, and never touches on what is likely to occur in that area.
Because... REASONS!
No really, it causes issues with the brain when the lens does not move with the eye. Like vertigo. Yes I RTFA.
What is wrong with thin clients?
You spend the same amount of money on screen and UI hardware, and then shave a sliver of the total system cost off by skimping on CPU and RAM, then spend much more than what you saved on beefed up network infrastructure to accomodate the larger payload. Thats what.
Thin clients only make sense as a way to salvage older thick clients when you just happen to have next to no money to spend, and already for some reason have an overpowered network and server infrastructure. Or if your user base is so supid that they cannot be trusted not to throw them in the dishwasher.
This. Looking at existing tests is also very educational. They often show where the codebase was confusing enough to cause recurring regressions.
The other place to make very, very sure to read is the repository commit logs, if you have them. They'll tell you a lot about why the code is in its current state, and will often show you where refactors have been left half-complete.
Anyways, it makes sense that air quality is worse in areas with less trees leading to higher rates of lung disease
Given the plumes of VOCs trees emit, no that makes no sense at all. Now, having a bunch of dead decaying trees lying around after being killed by an infestation, THAT impacting air quality would seem to make sense.
I work in an educational environment where we've done BYOD since before the acronym got coined. Even in this very permissive environment, we still insist that certain OSes pass a basic NAC sanity scan to reduce the disease vectors inside the firewall. (It's all easily circumenventable, but less trouble to circumvent than to comply.) This brings down the infection rate to a level manageable by the help desk and IT staff.
We do have IP and PII concerns. We address them organizationally by clearly defining the boundaries where work with certain types of information may occur through user education. This generally does not constrain users to the point of hurting innovation -- interacting with this type of data is only a small part of most jobs here. Companies that fixate on technical solutions to problems that can be solved organizationally are only hurting themselves.
So the end result is people can BYOD, but they are patched up (because bypassing the NAC is 30 minutes work versus 5 minutes complying) can't be running open servers on them (as the firewall won't let inbound connections in) and are not using them to process the latest payroll, because they mostly cannot get to that data due to host/firewall policy, and where they can, they know they shouldn't do that.
All that being said, a larger voltage with a low current, when sufficiently protected with a power negotiation protocol like that used in PoE, is going to be safer than a high current LV source. A sufficiently low voltage source might not be able to electrocute you, but it's pretty damn good at starting fires compared to a HV source with an effective input resistance.
good luck enforcing that on Linux. What are they going to do?
Tap into the other side of the conversation, where granma is running Windoze or OSX?
Which reminds me, you know how many times a year I get asked for a public key for email? About 0.2.
Pretty much the same reason I'm still here... I've managed to succeed enough to be comfortable, do so without pillaging, and work in an area that has potential to deliver productive change to the country. So I think I'll just keep that up.
If you want to make your life better, that's on you: it won't be handed to you.
Absolutely on target. The very first step to doing this, of course, is realizing theat "the system is rigged and the man is keeping you down", and the second is figuring out how to do something about that.
OR, you could buy into the idea that if you just stick your neck out far enough, some Donald Trump's next pyramid scheme won't milk you from what little cash or manpower you have at your disposal and instead will make you magnificently wealthy. But I would not recommend that.
Or use them as a captive board game opponent.
They were testing long-ish term exposure of the older mouse body to blood constantly filtered through the younger mouse's system. Doing that is apparently cheaper and more humane than harvesting and transfusing 24x7.
Any treatment they (meaning any sanely regulated or ethical medical establishment) develop from this won't expose the donor, that would violate a lot of laws, policies, codes and consciences.
It does give a new meaning to the term "Flash Mob"
While carrots and APAP are both in common use by the populance, carrots do
not provide instant relief from sudden onset of pain. When you burn yourself
with hot grits, you can either stand there and think "you know, if I had eaten
carrots instead then maybe I'd be in a better mood about burning myself with
hot grits" Or you can take a pain reliever.
So we need pain relievers, not just carrots.
Carrots also do not do another thing: kill you if you eat too much, with "too
much" being something you could get down in a single swallow, or gradually
take over the course of a day without any stomach cramps to let you know
you are doing something fatal. Carrots don't kill people or cause intractable
medical expenses when used improperly, barring some rather deviant
practices (sometimes involving hot grits as well).
As such, it's very important to understand the reasons why a person might
use these substances, so that we can educate the public about which
substances to use under what conditions. If APAP can help a person avoid
using a more damaging or addictive psycoactive phrametceutical, but
has to be used with care, we need to know that.
Anyway, scientists study diet just fine. They are even finally getting around
to studying intestinal flora in better detail. Of course there is a funding
bias when big pharma levels of money are involved, but that's just capitalism
and greed doing its usual damage when we fail to set good boundaries for it.
This. Anxiety and panic aren't always beneficial and they don't always end on their own.
Sometimes they run away with themselves in completely unproductive directions, and
will cause you to do some pretty crazy and potentially self-damaging things. Since your
brain has effectively been disabled, you can't just self-discipline your way out of them
either.
They can get so bad that you have to go the ER and have them break the feedback loop
with a Lorazepam or whatnot.
Not to mention the actual physical toll that cronic anxiety can have on the health of the
rest of your body (from extreme stress levels) is damaging to your longterm health.
Except it will leave you a walking dead man for a couple of days while your body tries to live without a functional liver, and doctors cannot do a thing about it. So that probably would be an even worse existential crisis.
The fact Javascript has a curly braces syntax doesn't mean it can't be a functional programming language.
Actually the thing that makes a functional language a functional language has nothing to do with curly braces. The defining principle of functional languages is that you have to have special hacks built into the language that technically violate it's functionality in order to make it do anything -- eh -- functional -- due to the fact that side effects are the only useful way to get anything done.
I'm also a bit concerned about this "netifd" creature. I'll have to figure out how to wedge it onto something I'm not using in production in order to play with it, but it seems at first blush to be removing a lot of scripting capabilities surrounding the network event system, which I use a lot, in ways that are not expressable/supported in /etc/config/network. It also takes the configuration further away from matching what happens on a normal linux host, which will create more of a dichotomy to code on both sides of.
Speaking as someone currently considering buying slightly behind the curve, I was all set to jump on an Intel-based fanless system because of the TDP figures. However, with the PowerVR versions of the Intel GPU c**k-blocking linux graphics, and with AMD finally open-sourcing UVD, I'm now back to considering a Brazos. Less choices for fanless pre-built systems, though. May have to skip on the pay-a-younger-geek-because-I-dont-enjoy-playing-legos-anymore part.
So no, for some markets, Intel has not yet realized the advantage that their IC processes should technically give them, and to the point of TFA, if they do not combine that advantage with architectural improvements, there will be ways for AMD to stay in this market for some time to come.
You would not think anyone would be so dumb to set these up but some may be legacy, or put in place by a local hero sysadmin.
A lot of these are spare aux or console ports on Cisco routers. The actual syntax used to set one up is a bit contorted, so it's possible for someone inexperienced who is following crib notes to think they are just enabling access to the serial port from the router commandline when in fact they are also enabling an alternate telnet/ssh port.
Also a few of the newer platforms coming out from Cisco include the ability to run a linux server on the second core ("embedded service module") and the default configuration has a rather permissive "transport output" statement on the emulated serial port joining the IOS to the ESM.
LOM has mitigated the need for most of these setups, but there is still gear where the only reliable rescue console is on the serial port.