It's not always bad. It depends on how you are using it. If you are thrashing around in directories and splicing into text files a whole lot to alter small fields of data, it isn't designed to do such things at quite the same speed as databases are, which is one reason why a number of CMS systems support DB backends rather than just plopping all the content down in files. Once you'd found an app that extensively used the fs, you'd have to look at why and how and make a call as to whether using a database instead might improve performance.
One option would be to take an existing FSF project which is currently abusing the filesystem as a database, and integrate optional database support into it, documenting and profiling performance as one proceeds. Something important and in common use would be good, but not so importantant that it needs to be present on systems before a DB service is up. So just install everything you can on a linux box and then go look for giant hairy directory trees in/var/lib/ and find out what project owns them.
As of this moment 3 of our core systems people have been in an all day meeting with outside consultants hired to help them with a task which would not exist but for arbitrary the whims of a cloud service provider.
Those seeking job security in local IT shops should welcome our new cloud-based overlords.
The approach used on the eduroam network could work. You sign up on an identity provider's network, and the identity provider takes care of handling the calls from the MPAA and turning you in. Mom and Pop's Mop Shop doesn't need to do anything but stand up the AP and wouldn't be liable. It would just take some time to get the WPA-Enterprise SP configuration into commodity equipment so they can turn it on with a checkbox, and a little time for the MPAA to learn to check the IDP's session lists before trying to hassle Mom and Pop.
that bash is, for some reason, eating Perl's lunch in the sysadmin/code-glue areas
What you are seeing here is init scripts gradually being expanded to include the functionality of tools written in Perl. There's a consitent inclination on the part of distros to include a minimalist set of core packages (despite the expanding size of installation media and system cababilities even on embedded systems). Bash serves as a lowest common denominator which, if the user base slogs away at it long enough, can be used to express the same functionality of utlities oriinally written in Perl, albeit somewhat less succinctly/maintainably.
Perl is only scary to those who have not practiced with it enough. Unless the author was trying to obfuscate or wasn't thinking clearly, those "line noise" scripts are actually easier to read than the equivalent 1000 lines of code distributed in 5 files that don't actually divide up functionality in any useful manner.
You're seriously going to criticize the aesthtic of inline regex literals from the shakey ground of a language that couldn't figure out a better function name than "preg_replace"?
The material in my sig might have been able to get their kit working from the printer PCB of a 1150 instead of adding an arduino, though there's still quite some work to do ferreting out the jet/cartridge control.
Isn't the enterprise solution to git to... host an origin on your own damn server?
No. The enterprise solution to git is to have a repo on the most popular site, so that when a random person wants to send a 4-line pull request, they probably already have an account on the service and won't be dissuaded.
Technically, neither are phonons "heat". Heat is energy in transit, and semantically is not strictly equivalent to any of the mechanisms or consequences of that transfer. However outside of a scientific treatment, this stricture is dropped.
OP is of course incorrect in assume that IR is the only mechanism by which heat can occur.
Looks like my sarcasm tags got eatern in my earlier post... it doesn't carry well over the net.
Well, I could tell. But detecting sarcasm is indeed hard over the net, because the former ALLCAPS people now try to blend in and you can never tell, being as they are horrible at controlling their tone.
For the most part, in an amusement park setting, assuming it doesn't include hotels, I find it hard to find this very creepy. It's not like you go to such a park to engage in seditious plots, or do not go in expecting to be aggressively advertised to while you are there.
What could creepy wierdos find out about your proximity to your kids with this?
This, however, is a tenable argument as to why it should feel creepy, because companies historically bungle such security concerns. Also the potential for the tech to be piloted in this setting and applied in completely different settings where it would indeed be very creepy.
Rest assured: to the people that hold this attitude, the lives of the lower quartile would be equally as foreign. They have no clue what poverty entails.
And forget even mentioning that the only truly self-sustaining tax system is one based entirely off property taxes (or more practically, to avoid excessively intrusive government auditing, on property insurance policies.)
Natural languages have context. A few languages have tried to spin this in. Larry Wall being a bonafide linguist, Perl6 seems to be trying to do so further (though on the other hand it is elimiating "want"-like constructs). Problem is some people really hate context because you actually have to know the language to read the language when there is context -- it is no longer a lowest common denominator where a few educated guesses gets you from knowing PHP to being able to mostly read Perl/Python/Ruby.
This sets up a real dichotomy -- language creators can intentionally refuse to add anything new or innovative in order to satisfy the people who only want to learn "pidgin", or they can innovate to a smaller audience.
And then you have to check for error conditions after resolving the IP address. And deal with blocking timeouts and/or use a nonblocking API.
This is not to say that DNS is to be avoided, just that it is nowhere near as easy to do it right as most users (and unfortunately, even some programmers) seem to think.
Yes and no, dot11ac requires 5GHZ radio support, and there are more channels available there -- and also consequently on a 5GHz network enterprises can pack APs more tightly without turning down the power level. So dot11h and other frequency conflict avoidance schemes should allow APs to automatically avoid each other. However, because of the 80MHz channel option, which will doubtless be turned on by just about everyone, this advantage is mitigated to half over a 40MHz dot11n network and to 1/4th of an unbonded dot11n network, because in that scheme, you may be taking less time to transmit the packet, but you are doing it over 4 channels instead of one, so you have to wait for all 4 to be clear and all 4 have to wait for you to be clear.
In addition spatialized MIMO should theoretically act not only as a bandwidth booster but also as a way to reduce crosstalk.
The real winner will be the 2.5GHz spectrum, because forcing vendors to put a 5GHz radio in means that we'll finally reach some level of sanity and balance between the two bands.
Slashdot Mirror
It's not always bad. It depends on how you are using it. If you are thrashing around in directories and splicing into text files a whole lot to alter small fields of data, it isn't designed to do such things at quite the same speed as databases are, which is one reason why a number of CMS systems support DB backends rather than just plopping all the content down in files. Once you'd found an app that extensively used the fs, you'd have to look at why and how and make a call as to whether using a database instead might improve performance.
One option would be to take an existing FSF project which is currently abusing the filesystem as a database, and integrate optional database support into it, documenting and profiling performance as one proceeds. Something important and in common use would be good, but not so importantant that it needs to be present on systems before a DB service is up. So just install everything you can on a linux box and then go look for giant hairy directory trees in /var/lib/ and find out what project owns them.
As of this moment 3 of our core systems people have been in an all day meeting with outside consultants hired to help them with a task which would not exist but for arbitrary the whims of a cloud service provider.
Those seeking job security in local IT shops should welcome our new cloud-based overlords.
The approach used on the eduroam network could work. You sign up on an identity provider's network, and the identity provider takes care of handling the calls from the MPAA and turning you in. Mom and Pop's Mop Shop doesn't need to do anything but stand up the AP and wouldn't be liable. It would just take some time to get the WPA-Enterprise SP configuration into commodity equipment so they can turn it on with a checkbox, and a little time for the MPAA to learn to check the IDP's session lists before trying to hassle Mom and Pop.
that bash is, for some reason, eating Perl's lunch in the sysadmin/code-glue areas
What you are seeing here is init scripts gradually being expanded to include the functionality of tools written in Perl. There's a consitent inclination on the part of distros to include a minimalist set of core packages (despite the expanding size of installation media and system cababilities even on embedded systems). Bash serves as a lowest common denominator which, if the user base slogs away at it long enough, can be used to express the same functionality of utlities oriinally written in Perl, albeit somewhat less succinctly/maintainably.
Perl is only scary to those who have not practiced with it enough. Unless the author was trying to obfuscate or wasn't thinking clearly, those "line noise" scripts are actually easier to read than the equivalent 1000 lines of code distributed in 5 files that don't actually divide up functionality in any useful manner.
Given the support for Junctions, it should last into the first gen of quantum-assisted computers :)
I hope you realize that's an in-joke among perl6'rs.
You're seriously going to criticize the aesthtic of inline regex literals from the shakey ground of a language that couldn't figure out a better function name than "preg_replace"?
The material in my sig might have been able to get their kit working from the printer PCB of a 1150 instead of adding an arduino, though there's still quite some work to do ferreting out the jet/cartridge control.
However as long as the efficiency is indeed 1.2-2% as mentioned in an adjacent comment this is no replacement for current A/C tech.
I guess that depends on how efficiently the fluoresced light (and refracted laser light) can be converted back into electricity.
Isn't the enterprise solution to git to... host an origin on your own damn server?
No. The enterprise solution to git is to have a repo on the most popular site, so that when a random person wants to send a 4-line pull request, they probably already have an account on the service and won't be dissuaded.
Technically, neither are phonons "heat". Heat is energy in transit, and semantically is not strictly equivalent to any of the mechanisms or consequences of that transfer. However outside of a scientific treatment, this stricture is dropped.
OP is of course incorrect in assume that IR is the only mechanism by which heat can occur.
That's what I read into the distinction as well. Of course, they could have just said "thermal phonons".
How can you say this!? It's Cloud! And Streaming! I bet they've even got plans for BYOD, VirtualSomething YetAnotherSomethingOverIP and CrowdSourcing.
Looks like my sarcasm tags got eatern in my earlier post... it doesn't carry well over the net.
Well, I could tell. But detecting sarcasm is indeed hard over the net, because the former ALLCAPS people now try to blend in and you can never tell, being as they are horrible at controlling their tone.
For the most part, in an amusement park setting, assuming it doesn't include hotels, I find it hard to find this very creepy. It's not like you go to such a park to engage in seditious plots, or do not go in expecting to be aggressively advertised to while you are there.
What could creepy wierdos find out about your proximity to your kids with this?
This, however, is a tenable argument as to why it should feel creepy, because companies historically bungle such security concerns. Also the potential for the tech to be piloted in this setting and applied in completely different settings where it would indeed be very creepy.
Rest assured: to the people that hold this attitude, the lives of the lower quartile would be equally as foreign. They have no clue what poverty entails.
And forget even mentioning that the only truly self-sustaining tax system is one based entirely off property taxes (or more practically, to avoid excessively intrusive government auditing, on property insurance policies.)
My first reaction was "no, please, don't encourage the twits."
They just need to get the laptops down to 25.5W, then they could run off PoE+, and they'd be able to put decent battery life in them.
Maybe call it USB SuperSpeed 3.1?
I vote for "USB_maybe_we_should_have_just_used_UTP_RJ45s_in_the_first_place."
It's a matter of volume really -- our ears are saturated. We bought a toner with a better filter. It helped a tiny bit.
Natural languages have context. A few languages have tried to spin this in. Larry Wall being a bonafide linguist, Perl6 seems to be trying to do so further (though on the other hand it is elimiating "want"-like constructs). Problem is some people really hate context because you actually have to know the language to read the language when there is context -- it is no longer a lowest common denominator where a few educated guesses gets you from knowing PHP to being able to mostly read Perl/Python/Ruby.
This sets up a real dichotomy -- language creators can intentionally refuse to add anything new or innovative in order to satisfy the people who only want to learn "pidgin", or they can innovate to a smaller audience.
And then you have to check for error conditions after resolving the IP address. And deal with blocking timeouts and/or use a nonblocking API.
This is not to say that DNS is to be avoided, just that it is nowhere near as easy to do it right as most users (and unfortunately, even some programmers) seem to think.
Yes and no, dot11ac requires 5GHZ radio support, and there are more channels available there -- and also consequently on a 5GHz network enterprises can pack APs more tightly without turning down the power level. So dot11h and other frequency conflict avoidance schemes should allow APs to automatically avoid each other. However, because of the 80MHz channel option, which will doubtless be turned on by just about everyone, this advantage is mitigated to half over a 40MHz dot11n network and to 1/4th of an unbonded dot11n network, because in that scheme, you may be taking less time to transmit the packet, but you are doing it over 4 channels instead of one, so you have to wait for all 4 to be clear and all 4 have to wait for you to be clear.
In addition spatialized MIMO should theoretically act not only as a bandwidth booster but also as a way to reduce crosstalk.
The real winner will be the 2.5GHz spectrum, because forcing vendors to put a 5GHz radio in means that we'll finally reach some level of sanity and balance between the two bands.