Never happened to me, but I've come close enough to have managed to develop a healthy "spider sense." Whenever I type "rm" at a hash prompt my adrenaline immediately spikes and I switch to hunt-and-peck-and-verify typing mode.
Well, not all, there are indeed "solar shingles", but they are pricey by comparison. Last time I looked, pricier than merited by the economics of replacing shingles.
I could see the side-benefits of an easily repairable/lightable/etc road system making up for the general stupidity of the idea. Of course, if you've ever driven on one of the concrete slab roadways like in upstate NY the constant clicking of the tires on the seams drives you batty after a while, and there'd be way more seams.
Roofs also need maintenance and replacing, and this is not cheap as any homeowner knows -- so the material displacement theory has to compete with that as well, though currently many rooftop solar installations do not replace shingles.
I bet we also get the solar-panels-in-space microwave beam stupid idea thing built before this is all over. Anything to avoid just doing the sensible boring thing and building the cheaper solutions.
and the need to revise existing code when adding a new method/function that has the same name as an existing one
Let's be precise: the need to add one multi to the one only sub that was allowed before you made it a multi. Compared to the benefits of being able to close the definition of the sub for the optimizer to inline it under more circumstances, this is a minor incovenience.
If such calling conventions are 'good' then why not use them for all subroutines?
Because different calling conventions are better at different things. Generally in he style that uses subs, you do not want an unknown named parameter to be ignored, but when inheritance is involved, you do.
It doesn't appear to have any revolutionary multi-threading/parallel processing magic that other languages don't have.
Other languages have hyper/race operators and composeable concurrency primitives baked into the core? News to me.
Time will tell. The same arguments you make could have been levied against, for instance, go. There's enough dissatisfaction with currently available languages that new ones crop up all the time. Perl 6 has aimed at producing something that will gain more users fed up with the status quo than it will lose to alternatives, and I think as it stabilizes, that objective will have been achieved. Unless it gets pushed in the media as a fad, all languages have to go through an adoption curve and this is the healthier way for it to grow, because it allows more feedback to be generated from less aggregate frustration.
Why do I have to go find other instances of the same sub/method and rename them 'multi' just because I now have 2 signatures?
So you can get compiler warnings when you accidentally try to shadow an 'only' sub definition in the same scope when you are not using multis.
why is there sub and method as separate things in the first place
Because calling conventions are customized to OO in methods -- you have an invocant, and unknown named parameters are, by default, ignored so you can easily subclass.
and WHY is 'sub' changed mysteriously to '->' when the method is anonymous
anonymous subs using "sub" still work. '->' is a generic closure syntax which you may prefer if you like it.
I'm having a hard time seeing what was gained
It's as much about what was lost than what was gained -- Perl 6 leaves behind a lot of the things that demanded a spirit of loyalty to put up with, like variant sigils, so it will be less irritating to a wider audience. The whole language is much more self-consistent, and things that would have required a complete overhaul of Perl 5 to implement have not had to contend with the obstacle of backwards compatibility.
Seconded. And FWIW pugs came before rakudo-parrot and helped a whole lot giving people something solid to play with to find the weak spots in initial plans.
Perl 6 does not discriminate, we even hug trolls, come on over.
Well, on professional grade routers/firewalls ACLs are compiled and pushed down to the FIB/CAM, which can indeed reject things in hardware. Some commodity cards also include onboard packet processors, but YMMV on support for configuring it.
As far as it generating alerts, that's the software's shortcoming for not supporting a way to selectivey silence alerts.
As far as the wasted bandwidth, if it is any consequenctial amount, you're pretty much without recourse unless you can show it is having a financial impact, and given home ISPs rarely give you access to metering information to do so, you're hosed.
In an enterprise setup where you are peering BGP to your ISP, the ISP might support BGP communities for selectively blackholing traffic from certain networks to your ranges at their border, on a limited basis (routers only have so much space to contain the rules so you'll only be alllowed a few prefixes.)
I can't help but imagine a world where lots of philanthropists fund the most talented CS/IT staff to work on world-changing beneficent technology, meanwhile the masses all have less than ten fingers because their knife-bearing IoT kitchen appliances were written by whatever idiot was left at the keyboard after our saviors left their respective industries.
I'm all for altruistic things, heck, I do some myself, but humility is often the first casualty of working "outside the system" -- when SV millionaires volunteer their money they tend to think big and reach high and ignore all the hard work that needs to be done on more mundane problems, and that's a powerful siren song to someone wading through a bunch of work that is well below their capabilities.
When I was in college I was training to design microchips -- a prestigious thing at the time. About halfway through that, I noticed that no matter how many more HZ the CPUs ran at, software was devolving at a rate to compensate. So I finished that degree and then totally did not go design microchips.
I got a blandish job deploying the technology we already had, because it does not matter what we have collecting dust on laboratory shelves, it's what ordinaty people can actually use that matters, and if smart people are too arrogant or elitist to wade into an everyday work environment and do some smart person things to improve it -- which yes will also requires doing some work that isn't particularly challenging, it'll just always be the same keystone cops routine.
So, i don't get to bummed when I read about stunning acheivements on phys.org and think I could have been working on that team if I'd chosen a different path, I just picture what an utter wreck my workplace might have become without me.
Mnemonics are for people who want to later have to remember which DSLs decided on "ne" and which ones decided on "neq" and hence lose most of the benefit.
The only real advantage to them is on the commandline so you don't have to escape shell syntax. Or when you actually make them do something subtly different (but useful) than the symbolic ones, as in Perl.
Except that the verification keys used are not public, and in general, no option to install additional trusted keys is made available. It basically kills the ability to have custom boot loaders for backup/restore or for any other reason and makes it rather easy to hard-brick the device as no utility to undo an unverifiable bootloader is made availble to the public. The age of mods is coming to an end unless consumer demand for devices that they can add keys to rises to unlikely levels.
(Often the keys are manufacturer specific and roms from different carriers can be booted on the same device, but the carriers could easily lobby the manufacturers to truly lock the devices they sell to their network.)
Well, for the more-BYOD-than-BYOD sector, what will happen is we'll install a new VPN that is not quite as crusty as our old one which always "just worked" and so never got budgeted for an upgrade, configure it for best practices security, and then weaken it when 10% the must-have clients turn out to be too crummy to deal and don't support installation of a 3rd party client, even if we could get front-row to shoulder the support burden involved in doing that (or doing an on-site CA and dealing with cert installation.)
(I'm going to try to sell the idea of forcing those weakest-link clients to use a different SAP IP so we can tell them apart and not cripple security for the rest, we'll see how that goes.)
As a customer of such software, I second that, and I resent being asked to do the job the vendor was too stupid to put on the payroll just to get their product to work.
AFAIK the most recent company to make a serious attempt at market penetration with flywheels was Beacon Power. They got as far as building one frequency regulation plant to operational status, and then the financials caught up with them; there's a private equity firm trying to put humpty dumpty back together again, we'll see how they do.
Just like flow batteries, it's a tech that needs a lot of up front money and work to scale out, and is stepping into a field where they have to compete with a variety of companies with different technology -- not all of them necessarily based on technology that uses resources that actually scale (e.g. giant plants of Li batteries are likely to later be scrapped when Li starts to be more expensive as mobile applications need it for gravimetric/volumetric energy density.) Investors can get reluctant when a breakout market trend towards one particular tech could make the others obsolete before they start turning a profit, and the pressure is always there to go back to the drawing board and improve the eventual economics at the cost of losing time in market development.
But mostly, nobody mentioned them because the article is about flow batteries, not flywheels.
Heck, good luck getting the big UPS manufacturers to even use established tech that's better/longer lasting than lead-acid. We'd be lucky if they moved to NiCad by 2025, decades after everyone else stopped using it.
I never claimed "Layer 0" was specified, don't be a moron, use your reading comprehension skills. You don't win arguments by mischaracterizing your opponent. And stop being so insulting. All I did was point out that "Layer 0" is in parlance, and that the extent to which physical media and infrastructure is "in the ISO model" is, by that own model's admission, been a gray area with gradually scope creep (they probably should have started with layer 3 or so to leave space to grow downward.)
At any rate, I will leave you and your personality disorders to amuse yourself insulting other people.
Hey man whatever, I hear the term "Layer 0" at least once a week, so I know I'm no wrog there. We always get a chuckle when a wet-behind-the-ears hire starts making a fuss over OSI mode pedantry, BTW.
An example of a "Layer 1" attack would be an RF interferer. This is clearly a "Layer 0" attack.
Physical Media: Any means in the physical world for transferring
signals between OSI systems. Considered to be outside the OSI Model,
and therefore sometimes referred to as "Layer 0." The physical
connector to the media can be considered as defining the bottom
interface of the Physical Layer, i.e., the bottom of the OSI
One thing you have to realize about networking career folks is they are always tired and have forgotten more than many people know due to their horrible sleep habits/job requirements, so honestly, it was just a slip of the neurons. Do always ask us to verify our answers though because often we are kinda phasing in and out of reality.
I meant to say, physical layer, sorry, tired, so NRZI etc. Really the whole thing is rather fungible with protocols that don't fit cleanly into the classifications, but for the most part layer 1 is mostly high frequency bit encodings that don't actually demand certain voltage/current specifications.
Slashdot Mirror
"The only advantage Firefox gives is that one can run NoScript to block all scripting completely."
One other -- the only reason I use it -- it still has a fully functional separate persistent search box instead of that stupid omnibar.
Stark says "You do? Then we'll make it work" though it sounded like "That won't make it work" when I heard it, which would have been a funnier line.
I dunno, enjoy each other's company, learn stuff, and deal with emergencies robots don't know how to fix?
Asparagus is also a pretty interesting looking adult plant, especially covered in dew.
Never happened to me, but I've come close enough to have managed to develop a healthy "spider sense." Whenever I type "rm" at a hash prompt my adrenaline immediately spikes and I switch to hunt-and-peck-and-verify typing mode.
Well, not all, there are indeed "solar shingles", but they are pricey by comparison. Last time I looked, pricier than merited by the economics of replacing shingles.
I could see the side-benefits of an easily repairable/lightable/etc road system making up for the general stupidity of the idea. Of course, if you've ever driven on one of the concrete slab roadways like in upstate NY the constant clicking of the tires on the seams drives you batty after a while, and there'd be way more seams.
Roofs also need maintenance and replacing, and this is not cheap as any homeowner knows -- so the material displacement theory has to compete with that as well, though currently many rooftop solar installations do not replace shingles.
I bet we also get the solar-panels-in-space microwave beam stupid idea thing built before this is all over. Anything to avoid just doing the sensible boring thing and building the cheaper solutions.
and the need to revise existing code when adding a new method/function that has the same name as an existing one
Let's be precise: the need to add one multi to the one only sub that was allowed before you made it a multi. Compared to the benefits of being able to close the definition of the sub for the optimizer to inline it under more circumstances, this is a minor incovenience.
If such calling conventions are 'good' then why not use them for all subroutines?
Because different calling conventions are better at different things. Generally in he style that uses subs, you do not want an unknown named parameter to be ignored, but when inheritance is involved, you do.
It doesn't appear to have any revolutionary multi-threading/parallel processing magic that other languages don't have.
Other languages have hyper/race operators and composeable concurrency primitives baked into the core? News to me.
Time will tell. The same arguments you make could have been levied against, for instance, go. There's enough dissatisfaction with currently available languages that new ones crop up all the time. Perl 6 has aimed at producing something that will gain more users fed up with the status quo than it will lose to alternatives, and I think as it stabilizes, that objective will have been achieved. Unless it gets pushed in the media as a fad, all languages have to go through an adoption curve and this is the healthier way for it to grow, because it allows more feedback to be generated from less aggregate frustration.
Why do I have to go find other instances of the same sub/method and rename them 'multi' just because I now have 2 signatures?
So you can get compiler warnings when you accidentally try to shadow an 'only' sub definition in the same scope when you are not using multis.
why is there sub and method as separate things in the first place
Because calling conventions are customized to OO in methods -- you have an invocant, and unknown named parameters are, by default, ignored so you can easily subclass.
and WHY is 'sub' changed mysteriously to '->' when the method is anonymous
anonymous subs using "sub" still work. '->' is a generic closure syntax which you may prefer if you like it.
I'm having a hard time seeing what was gained
It's as much about what was lost than what was gained -- Perl 6 leaves behind a lot of the things that demanded a spirit of loyalty to put up with, like variant sigils, so it will be less irritating to a wider audience. The whole language is much more self-consistent, and things that would have required a complete overhaul of Perl 5 to implement have not had to contend with the obstacle of backwards compatibility.
Seconded. And FWIW pugs came before rakudo-parrot and helped a whole lot giving people something solid to play with to find the weak spots in initial plans.
Perl 6 does not discriminate, we even hug trolls, come on over.
Well, on professional grade routers/firewalls ACLs are compiled and pushed down to the FIB/CAM, which can indeed reject things in hardware. Some commodity cards also include onboard packet processors, but YMMV on support for configuring it.
As far as it generating alerts, that's the software's shortcoming for not supporting a way to selectivey silence alerts.
As far as the wasted bandwidth, if it is any consequenctial amount, you're pretty much without recourse unless you can show it is having a financial impact, and given home ISPs rarely give you access to metering information to do so, you're hosed.
In an enterprise setup where you are peering BGP to your ISP, the ISP might support BGP communities for selectively blackholing traffic from certain networks to your ranges at their border, on a limited basis (routers only have so much space to contain the rules so you'll only be alllowed a few prefixes.)
I can't help but imagine a world where lots of philanthropists fund the most talented CS/IT staff
to work on world-changing beneficent technology, meanwhile the masses all have less than
ten fingers because their knife-bearing IoT kitchen appliances were written by whatever idiot
was left at the keyboard after our saviors left their respective industries.
I'm all for altruistic things, heck, I do some myself, but humility is often the first casualty
of working "outside the system" -- when SV millionaires volunteer their money they tend to
think big and reach high and ignore all the hard work that needs to be done on more mundane
problems, and that's a powerful siren song to someone wading through a bunch of work
that is well below their capabilities.
When I was in college I was training to design microchips -- a prestigious thing at the time.
About halfway through that, I noticed that no matter how many more HZ the CPUs ran at,
software was devolving at a rate to compensate. So I finished that degree and then totally
did not go design microchips.
I got a blandish job deploying the technology we already had, because it does not matter
what we have collecting dust on laboratory shelves, it's what ordinaty people can actually
use that matters, and if smart people are too arrogant or elitist to wade into an everyday work
environment and do some smart person things to improve it -- which yes will also requires
doing some work that isn't particularly challenging, it'll just always be the same keystone cops
routine.
So, i don't get to bummed when I read about stunning acheivements on phys.org and think
I could have been working on that team if I'd chosen a different path, I just picture what an
utter wreck my workplace might have become without me.
urban driver, stopping-starting in traffic all day, not going very far
Kinda the sweet spot for hybrid-electric drives, no?
Mnemonics are for people who want to later have to remember which DSLs decided on "ne" and which ones decided on "neq" and hence lose most of the benefit.
The only real advantage to them is on the commandline so you don't have to escape shell syntax. Or when you actually make them do something subtly different (but useful) than the symbolic ones, as in Perl.
Except that the verification keys used are not public, and in general, no option to install additional trusted keys is made available. It basically kills the ability to have custom boot loaders for backup/restore or for any other reason and makes it rather easy to hard-brick the device as no utility to undo an unverifiable bootloader is made availble to the public. The age of mods is coming to an end unless consumer demand for devices that they can add keys to rises to unlikely levels.
(Often the keys are manufacturer specific and roms from different carriers can be booted on the same device, but the carriers could easily lobby the manufacturers to truly lock the devices they sell to their network.)
Well, for the more-BYOD-than-BYOD sector, what will happen is we'll install a new VPN that is not quite as crusty as our old one which always "just worked" and so never got budgeted for an upgrade, configure it for best practices security, and then weaken it when 10% the must-have clients turn out to be too crummy to deal and don't support installation of a 3rd party client, even if we could get front-row to shoulder the support burden involved in doing that (or doing an on-site CA and dealing with cert installation.)
(I'm going to try to sell the idea of forcing those weakest-link clients to use a different SAP IP so we can tell them apart and not cripple security for the rest, we'll see how that goes.)
As a customer of such software, I second that, and I resent being asked to do the job the vendor was too stupid to put on the payroll just to get their product to work.
AFAIK the most recent company to make a serious attempt at market penetration with flywheels was Beacon Power. They got as far as building one frequency regulation plant to operational status, and then the financials caught up with them; there's a private equity firm trying to put humpty dumpty back together again, we'll see how they do.
Just like flow batteries, it's a tech that needs a lot of up front money and work to scale out, and is stepping into a field where they have to compete with a variety of companies with different technology -- not all of them necessarily based on technology that uses resources that actually scale (e.g. giant plants of Li batteries are likely to later be scrapped when Li starts to be more expensive as mobile applications need it for gravimetric/volumetric energy density.) Investors can get reluctant when a breakout market trend towards one particular tech could make the others obsolete before they start turning a profit, and the pressure is always there to go back to the drawing board and improve the eventual economics at the cost of losing time in market development.
But mostly, nobody mentioned them because the article is about flow batteries, not flywheels.
Heck, good luck getting the big UPS manufacturers to even use established tech that's better/longer lasting than lead-acid. We'd be lucky if they moved to NiCad by 2025, decades after everyone else stopped using it.
I never claimed "Layer 0" was specified, don't be a moron, use your reading comprehension skills. You don't win arguments by mischaracterizing your opponent. And stop being so insulting. All I did was point out that "Layer 0" is in parlance, and that the extent to which physical media and infrastructure is "in the ISO model" is, by that own model's admission, been a gray area with gradually scope creep (they probably should have started with layer 3 or so to leave space to grow downward.)
At any rate, I will leave you and your personality disorders to amuse yourself insulting other people.
Hey man whatever, I hear the term "Layer 0" at least once a week, so I know I'm no wrog there. We always get a chuckle when a wet-behind-the-ears hire starts making a fuss over OSI mode pedantry, BTW.
An example of a "Layer 1" attack would be an RF interferer. This is clearly a "Layer 0" attack.
Layer 1 ends at bit encoding.
Physical Media: Any means in the physical world for transferring
signals between OSI systems. Considered to be outside the OSI Model,
and therefore sometimes referred to as "Layer 0." The physical
connector to the media can be considered as defining the bottom
interface of the Physical Layer, i.e., the bottom of the OSI
Here, and yes, we do. This is not a new thing.
One thing you have to realize about networking career folks is they are always tired and have forgotten more than many people know due to their horrible sleep habits/job requirements, so honestly, it was just a slip of the neurons. Do always ask us to verify our answers though because often we are kinda phasing in and out of reality.
Availability of $13 generics for drugs that cost $750 here?
The hypothesized cost of $25 per sample was bandied about as feasible by the similar (same?) process VirScan.
I wish them luck. We may eventually be able to figure out just how widespread things like lyme disease really are.
I meant to say, physical layer, sorry, tired, so NRZI etc. Really the whole thing is rather fungible with protocols that don't fit cleanly into the classifications, but for the most part layer 1 is mostly high frequency bit encodings that don't actually demand certain voltage/current specifications.