No, you may be thinking of an early prototype, named pugs, written in Haskell as part of the whirpool design process. The pool has whirled several times since then. I really admire the attention to detail that's been put into the Perl 6 specification and the implementation is coming along nicely and is already very usable for both small ad-hoc scripts and larger stuff, too. Just not for high performance quite yet and a few places where you have to work around some TODOs.
Also I'll be enjoying (really, not sarcastically) years of using Perl5 and Perl6 in the same file due to the easy integration between the two, replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.
On top of all this, Apple WiFi is especially broken because:
1) The station will never hop to the best AP when it should, it always waits until signal drops to -75dBm before roaming, so it continues to use the AP at the door where you walked in the building,. not the one near where you are sitting, ruining WiFi for everyone with low-rate shouting. Apple thinks we are going to carefully tweak our networks around this weakness (this is their stated offcial position on the matter) and they are wrong.
2) Responding to a bluetooth beacon from various Apple gadgets, the Apples will try to subvert the local WiFi network and communicate directly on channel 149. They won't even try the local network first to see if it is usable, instead they will try to multiplex the radio hardware between 149 and whatever other channel is actually being used. Meanwhile they fire up a radio on chanel 149, which is a common primary channel for bonded 40/80 channel groups, no matter what else is around trying to use it. Apple thinks we are going to hobble our 40MHz/non-DFS and 80Mhz/DFS channel bonding plan by taking all the APs off 149 (also their official position.) They are wrong.
3) Apple cannot manage to get their autodiscovery protocols to shut up long enough to let wifi and bluetooth hardware settle into a usable state. They think having their devices constantly scanning for gadgets is a terrific idea. They are wrong.
4) Apple keeps removing control over the WiFi from the users, preventing them from properly configuring their chipsets for a particular network, or even locking to a specific AP or turn off a band to help network admins troubleshoot a problem. Every new version of the OS, more options for control of the WiFi disappear from the UI. They think every network operator is going to provide.mobileconfig files to set these options. They are wrong.
5) For years, Apple has stubbornly refused to implement and support OKC. They think that because their iPads now support 11k this is no longer a problem and we will all just enable 11k even though it will break a bunch of other legacy devices (including iPads too old to run 11k) which still account for a large percentage of our users. They are wrong. And also they won't say whether they ever plan to support 11k on the OSX side.
Scientists trust scientists in other fields because they assume scientists have based their opinions on solid scientific evidence.
Unfortunately, they also are subject to the fundamental human bias that, when you model the behavior, you tend to base your model on what you know about yourself. Even if you know. intellectually, how dumbass a large portion of the population is, when it comes to projecting their predicted behavior, you'll be subject to this bias at some level. So for example, while a majority of scientists support more nuclear power, the majority of scientists are imagining nuclear power plants not built on disaster-prone real estate, because after all, who would do that?
Supposing there is no way to close it faster than it renders, sure they will be confused, but most will just blow it off as just another windows UI flub, close it, and enter their password.
Lockscreens in general only exist to satisfy PHBs and annoy the user. If you really cannot trust the physical security of your office environment for more than 10 minutes, you probably should not be trusting it for even 1 minute and be locking your system through other means.
Well, the problem can be solved by adjusting the "as long as you want it to" input into the equation.
Step back, take a look at the temporary naure of life, appreciate your own insignificance, and ask yourself, does it really matter if, when I'm 95 and cannot remember my own name, I still have photos of the cat I had in college.
Yep, smokes and trips to the soda machine for a diet cola keep my legs from getting cramped. Also sometimes keeps my coworkers from getting verbally raked and expells unwanted company from out of my office.
Last time I looked at that feature it was a smattering of different BIOS implementations. Nothing standardized, and I'm not entirely sure M$ has kept their support for setting it from inside the OS intact. PITA.
Yep. Wikipedia is successful because it takes input without an account, wich gets you hooked enough to actually create an account and also lets spam die a quicker death because even aloof bystanders can kill it. That and of course version control make reverts easier than spam. Like a few others that have burst on the scene with hopes of being "wikipedia for X", this site won't be very successful (unless its intended entirely as a credential collector.)
Same story here. It's one thing to retir support for older discrete cards out of the proprietary driver. Users of those cards tend to upgrade pretty frequently anyway. It's another thing entirely to retire support for embedded laptop chipsets, and while doing that, apparently not give the OpenSource maintainers good enough documentation on the power management/clocking in those chipsets to prevent overheats/instability.
I'm due for a new laptop here at work. My top requirement was "not AMD."
In some countries keeping data, especially customer data, longer then needed can cause legal problems as well.
Just about anywhere where a discovery motion can compell you to spend your own staff's time and effort answering questions about whether or not you have data X and please give data X to the lawyers, you want a data retention policy so that when you get that letter, you can just say "it's our policy to delete stuff older than Y, so X is long gone." Otherwise your techs are fumbling around in desk drawers and tape archives for old backups so you can say "yep, we looked."
If you don't draw analogies (like anthropomorphism), or abstractions, how the hell do you choose your names in a way that lends itself to understandable code? The author should take his own argument one step further and realize that calling a string of bits a "student" is likewise anthropomorphising the data, and calling another memloc a "Classroom" is applying an anology to what is really going on. Then he could reduce is argument ad-absurdium to requiring that all identifiers be randomly chosenstring to avoid installing unintentional meaning into data structures and procedures/functions.
FP has been rejected by programmers far too long, but the simple mechanism of immutability removes that most bothersome of bugs
...and kills you rmemory/cache profile. FP is great for a subset of problems, but should not be held up on a pedestal, just appreciaed as one tool in the box.
FP should already be easier to reason about than procedural programming
Considering it makes many everyday things harder to express, the fact that FP lends itself to easy modeling is offloading the mental effort in the wrong place. You're buying academic ease of manipulation at te expense of increasing the drudgery of everyday tasks, which is why FP is favored for research but not generally accepted for application.
Yes, it has been easier in general to move out of the way than some of the other desktop junk. Some of the automated editing of config files was annoying but at least how to kick it off an interface was easy to find and no other applications were so tangled up with it that they got cranky without it running, unlike avahi which always causes error message spew everywhere when it is down and over the years has been a game of whack-a-mole to keep it killed what with all the different ways it got started.
In general other than the smurfword name and the fact that I'm always elbow deep in network stuff and cannot have it interfering I think it's been a net positive to have around.
I wonder if it will make a push towards becoming an 11u cred manager. We do need a good UI for that if the rank and file users are ever to use 11u for something other than letting providers find ways to monetize their use of hotspots.
My best guess as to why they would mess with that is they wanted to fix a few issues where the standalone DHCP clients were not re-negotiating when they needed to, and of course they wanted to do it over DBUS. The alternative fix would have been to work with DHCP client projects/maintainers to add pluggable DBUS control interfaces to those, but when given the choice between that and mission creep, mission creep wins these days. Unless they just decided to use the systemd DHCP client they put in there for use booting containers, and that is what is being referred to.
The other hard components to wrangle are pptpd/pppd/l2tpd (convincing them to hang up when they should, and getting them to promptly relinquish their device node so rules written against ppp0 don't have to be yanked back out and reinstalled when it changes to ppp1 after a tunnel rebuilds.) I wonder how long until they roll their own of those instead of helping improve them.
People just cannot resist the ease of communication. Email is the crack cocaine of IT security.
I've always maintained the most devastating payload a worm could have would be forwarding random things from sent-mail to random receipients in the contacts list, considering how so many lead incredibly dishonest lives.
Slashdot Mirror
IIRC, the Christmas release will be tagged 6.0.0. That was sort of a misinterpretation of an off-the-cuff remark.
No, you may be thinking of an early prototype, named pugs, written in Haskell as part of the whirpool design process. The pool has whirled several times since then. I really admire the attention to detail that's been put into the Perl 6 specification and the implementation is coming along nicely and is already very usable for both small ad-hoc scripts and larger stuff, too. Just not for high performance quite yet and a few places where you have to work around some TODOs.
Perl6 version, FWIW:
@Lines .= sort: *.Name
Also I'll be enjoying (really, not sarcastically) years of using Perl5 and Perl6 in the same file due to the easy integration between the two, replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.
I really like this language a lot.
On top of all this, Apple WiFi is especially broken because:
1) The station will never hop to the best AP when it should, it always waits until signal drops to -75dBm before roaming, so it continues to use the AP at the door where you walked in the building,. not the one near where you are sitting, ruining WiFi for everyone with low-rate shouting. Apple thinks we are going to carefully tweak our networks around this weakness (this is their stated offcial position on the matter) and they are wrong.
2) Responding to a bluetooth beacon from various Apple gadgets, the Apples will try to subvert the local WiFi network and communicate directly on channel 149. They won't even try the local network first to see if it is usable, instead they will try to multiplex the radio hardware between 149 and whatever other channel is actually being used. Meanwhile they fire up a radio on chanel 149, which is a common primary channel for bonded 40/80 channel groups, no matter what else is around trying to use it. Apple thinks we are going to hobble our 40MHz/non-DFS and 80Mhz/DFS channel bonding plan by taking all the APs off 149 (also their official position.) They are wrong.
3) Apple cannot manage to get their autodiscovery protocols to shut up long enough to let wifi and bluetooth hardware settle into a usable state. They think having their devices constantly scanning for gadgets is a terrific idea. They are wrong.
4) Apple keeps removing control over the WiFi from the users, preventing them from properly configuring their chipsets for a particular network, or even locking to a specific AP or turn off a band to help network admins troubleshoot a problem. Every new version of the OS, more options for control of the WiFi disappear from the UI. They think every network operator is going to provide .mobileconfig files to set these options. They are wrong.
5) For years, Apple has stubbornly refused to implement and support OKC. They think that because their iPads now support 11k this is no longer a problem and we will all just enable 11k even though it will break a bunch of other legacy devices (including iPads too old to run 11k) which still account for a large percentage of our users. They are wrong. And also they won't say whether they ever plan to support 11k on the OSX side.
Scientists trust scientists in other fields because they assume scientists have based their opinions on solid scientific evidence.
Unfortunately, they also are subject to the fundamental human bias that, when you model the behavior, you tend to base your model on what you know about yourself. Even if you know. intellectually, how dumbass a large portion of the population is, when it comes to projecting their predicted behavior, you'll be subject to this bias at some level. So for example, while a majority of scientists support more nuclear power, the majority of scientists are imagining nuclear power plants not built on disaster-prone real estate, because after all, who would do that?
Supposing there is no way to close it faster than it renders, sure they will be confused, but most will just blow it off as just another windows UI flub, close it, and enter their password.
Lockscreens in general only exist to satisfy PHBs and annoy the user. If you really cannot trust the physical security of your office environment for more than 10 minutes, you probably should not be trusting it for even 1 minute and be locking your system through other means.
Well, the problem can be solved by adjusting the "as long as you want it to" input into the equation.
Step back, take a look at the temporary naure of life, appreciate your own insignificance, and ask yourself, does it really matter if, when I'm 95 and cannot remember my own name, I still have photos of the cat I had in college.
It's called the Zen backup plan.
I'm sure some high frequency trader could figure out some sleazy way to make a buck off it, though.
Yep, smokes and trips to the soda machine for a diet cola keep my legs from getting cramped. Also sometimes keeps my coworkers from getting verbally raked and expells unwanted company from out of my office.
Though, it would be even nicer to get hazard pay for it.
Last time I looked at that feature it was a smattering of different BIOS implementations. Nothing standardized, and I'm not entirely sure M$ has kept their support for setting it from inside the OS intact. PITA.
Well, the lead plaintiff can be awarded a significant amount by the court for his/her troubles. It is pretty much entirely up to the court, however.
Yep. Wikipedia is successful because it takes input without an account, wich gets you hooked enough to actually create an account and also lets spam die a quicker death because even aloof bystanders can kill it. That and of course version control make reverts easier than spam. Like a few others that have burst on the scene with hopes of being "wikipedia for X", this site won't be very successful (unless its intended entirely as a credential collector.)
Same story here. It's one thing to retir support for older discrete cards out of the proprietary driver. Users of those cards tend to upgrade pretty frequently anyway. It's another thing entirely to retire support for embedded laptop chipsets, and while doing that, apparently not give the OpenSource maintainers good enough documentation on the power management/clocking in those chipsets to prevent overheats/instability.
I'm due for a new laptop here at work. My top requirement was "not AMD."
In some countries keeping data, especially customer data, longer then needed can cause legal problems as well.
Just about anywhere where a discovery motion can compell you to spend your own staff's time and effort answering questions about whether or not you have data X and please give data X to the lawyers, you want a data retention policy so that when you get that letter, you can just say "it's our policy to delete stuff older than Y, so X is long gone." Otherwise your techs are fumbling around in desk drawers and tape archives for old backups so you can say "yep, we looked."
What gets me is this:
If you don't draw analogies (like anthropomorphism), or abstractions, how the hell do you choose your names in a way that lends itself to understandable code? The author should take his own argument one step further and realize that calling a string of bits a "student" is likewise anthropomorphising the data, and calling another memloc a "Classroom" is applying an anology to what is really going on. Then he could reduce is argument ad-absurdium to requiring that all identifiers be randomly chosenstring to avoid installing unintentional meaning into data structures and procedures/functions.
Also the future typical user will be using more speech recognition, computer vision, and "AI" experts, all of which scale with parallelism.
FP has been rejected by programmers far too long, but the simple mechanism of immutability removes that most bothersome of bugs
...and kills you rmemory/cache profile. FP is great for a subset of problems, but should not be held up on a pedestal, just appreciaed as one tool in the box.
FP should already be easier to reason about than procedural programming
Considering it makes many everyday things harder to express, the fact that FP lends itself to easy modeling is offloading the mental effort in the wrong place. You're buying academic ease of manipulation at te expense of increasing the drudgery of everyday tasks, which is why FP is favored for research but not generally accepted for application.
This thing would never go out. I mean, is there pretty much anywhere you can stand that doesn't have at least an HP printer ad-hoccing away?
Thank you. Very helpful of you.
Yes, it has been easier in general to move out of the way than some of the other desktop junk. Some of the automated editing of config files was annoying but at least how to kick it off an interface was easy to find and no other applications were so tangled up with it that they got cranky without it running, unlike avahi which always causes error message spew everywhere when it is down and over the years has been a game of whack-a-mole to keep it killed what with all the different ways it got started.
In general other than the smurfword name and the fact that I'm always elbow deep in network stuff and cannot have it interfering I think it's been a net positive to have around.
I wonder if it will make a push towards becoming an 11u cred manager. We do need a good UI for that if the rank and file users are ever to use 11u for something other than letting providers find ways to monetize their use of hotspots.
My best guess as to why they would mess with that is they wanted to fix a few issues where the standalone DHCP clients were not re-negotiating when they needed to, and of course they wanted to do it over DBUS. The alternative fix would have been to work with DHCP client projects/maintainers to add pluggable DBUS control interfaces to those, but when given the choice between that and mission creep, mission creep wins these days. Unless they just decided to use the systemd DHCP client they put in there for use booting containers, and that is what is being referred to.
The other hard components to wrangle are pptpd/pppd/l2tpd (convincing them to hang up when they should, and getting them to promptly relinquish their device node so rules written against ppp0 don't have to be yanked back out and reinstalled when it changes to ppp1 after a tunnel rebuilds.) I wonder how long until they roll their own of those instead of helping improve them.
People just cannot resist the ease of communication. Email is the crack cocaine of IT security.
I've always maintained the most devastating payload a worm could have would be forwarding random things from sent-mail to random receipients in the contacts list, considering how so many lead incredibly dishonest lives.