50 miles west of Chicago, I get about 40 digital channels, most with perfect pictures from my attic antenna. Free, but some channels are in Spanish and Polish !
The transition to digital was painless and good, more channels, better picture.
I wouldn't exactly call it "painless", but probably overall a good thing.
I still feel like certain channel frequencies should have been left operational if only for public safety and emergency purposes. You do not need transistors to wire up a black-and-white analog signal television receiver.
The third problem is RPM. It's an antiquated package format. They should use APT instead. Then DNF can be discarded in favor of the APT tools. Problem solved.
Pretty sure you're trolling, but I do take issue with this. RPM is perfectly fine, especially compared to raw.dkpg (spec files are comprehensible, and the ability to have a %verifyscript alone is a major, major win)). In regards to apt, even yum (with its plugin ecosystem) had a number of benefits over apt-get and cousins. I'm no fan of DNF and still consider it to be a classic case of someone's pet project and pet API winning out solely because the conservatives yelling "stop" were looking away for a moment, but this is in line with all the other bone-headed things Fedora was doing around that time...:/
Top US General concerned about future job security. Worries the human element will soon not be a requirement when it comes to warfare.
This is a big deal in a country where War and Combat are glorified and have seeped into the facets of everyday life.
Lol. If you think "War" and "Combat" have seeped into everyday life in some countries, just wait till you live in a world without at least some amount of Pax Americana...
Good luck with that nowadays with police being more aggressive at picking up unaccompanied minors walking to and from the public library.
If you have a teen curfew in your area, take that up with your local city council. If you don't have a teen curfew in your area and that's happening, you might have bigger problems going on...
The information age began long before Nest or the iPhone. Also, the Nest is a piece of shit.
He's not talking about the information age, he's talking about constantly-available mobile data access to the information.
Kids (mostly nerdy kids) being stuck in front of a desktop computer a la the 90s and early 2000s is not the same thing as everyone glued to their smartphones 24/7, or tablets being used as pacifying devices from the age of toddlers on up.
Previous generations had similar problems. It's just they have forgotten about them. Spreading rumours? That happened with kids writing messages about each other and putting them on the school noticeboards. Rumours could spread simply by word of mouth without any need for Twitter, Facebook or IM. Teenagers would spend hours talking to each other by telephone.
You're missing the point. Just as the telephone (and long distance telephone) was an exponential leap in communication -- a communications revolution -- that drastically affected society, constant data interaction (the tipping point seemed to be smartphones with 4G-ish speeds) is ALSO an exponential leap.
The problem is that this second leap combines the mutliband communication power of the internet with the psychological attachment issues of a Skinner box, partly as a result of most of the Internet being funded by advertising dollars and sponsorship. Facebook, YouTube, and many other things wouldn't feel the need to be (quite) so addictive if they were simple subscription services instead of demographic tracking opportunities for selling micro-targeted ads.
Want more proof that it was a revolution? I'm hard-pressed to think of *any* science fiction stories or films of the 20th century that accurately predicted the psychological impact of always-on mobile data access that we're seeing now. Sure, plenty of stories imagined the technology (think Star Trek TNG's PADD's, etc), but no one seems to have predicted the impact on human sociology that we're already seeing. It wasn't expected.
Many people turned the other way, trusting that RH (which had just seamlessly switched from traditional init to upstart in the previous release) wouldn't do anything particularly dumb. We were wrong. Or we assumed that Fedora's community would self-correct.
All through the F14 and F15 release cycles concerns were raised as feature and scope creep began to set in (even then). Many people "knew it would (likely) suck" because things were getting out of hand (and they remembered how LP had screwed up PulseAudio) and spoke up about it.
Possibly also SELinux problems. I've seen policy problems silently freeze startup for no reason that were quite tricky to resolve. And a policy rollback in RHEL7.1 ended with me wiping and rebuilding the box.
"Making unit files more portable" is a euphemism for "enforcing our standard on other systems and distributions".
If "0day" is a valid user on a system, there's absolutely ZERO reason why "User=0day" shouldn't be valid config on a system management tool (let alone an init replacement) that runs on that system. I don't care what other distributions do.
LP, once again, shows us that he thinks "Doesn't work on anything except my laptop with my particular setup" is a feature, not a bug, for middleware he's snuck into every distro out there.
Holy shit, it's like we've forgotten about the major privacy implications of the first version of this: Google Desktop
Many privacy and civil liberties groups such as the Electronic Frontier Foundation (EFF) have concerns that personal information on people's computers could readily be copied from users' hard drives.
Google Desktop version 3 contains certain features that raise serious security and privacy concerns. Specifically, the share across computers feature, which introduces the ability to search content from desktop to desktop, greatly increases the risk to users' privacy. If Google Desktop V.3 is set to allow Search Across Computers, files on an indexed computer are copied to Google's servers. The potential for information stored on their computers to be accessed by others if they enable this feature of Google Desktop v. 3 on their computers should be seriously considered. The EFF advises against using this feature.[17] Also, those who have confidential data on their work or home computers should not enable this feature. There are privacy laws and company policies that could be violated through the installation of this feature, specifically, SB 1386, HIPAA, FERPA, GLBA and Sarbanes-Oxley.
Other more far reaching concerns arise around the packaging and end user license agreement – specifically the level of intrusion on the local machine and the disclaimers that users implicitly agree to future changes in the license agreement without actually being able to see them immediately. - https://en.wikipedia.org/wiki/Google_Desktop#Privacy
Sure it can. Have you seen what demo makers can do with procedural generation?
Something that does a best-effort analog to digital conversion into equations and not samples would "compress down" that much because you're not really compressing at all, but re-creating from scratch into something approximating what was there. Think of an automated MOD/trakker creator.
Funny thing is she did not get arrested by Trump or the administration but by the FBI. When you break the law it is law enforcement that comes after you. If you listen to this kind of headline you would think that Trump had singled her out or something.
The FBI is part of the Executive Branch. Perhaps you missed that part in civics class.
So... The bomb goes off in the hold and starts a fire? Jets don't usually recover from that... At least up top, you might confine the damage to a hole next to whoever has the laptop bomb (Egypt Air...)
Jets possibly can recover from that, depending on placement and how reinforced the baggage hold is.
Jets can't recover from sudden depressurization via gaping hole in the cabin. The only reason the Daallo Airlines flight in Somalia wasn't worse was because the bomb next to the window went off before they had reached cruising altitude and the cabin was pressurized.
The security source said both bans were not the result of a single specific incident but a combination of factors.
One of those, according to the source, was the discovery of a plot to bring down a plane with explosives hidden in a fake iPad that appeared as good as the real thing. Other details of the plot, such as the date, the country involved and the group behind it, remain secret.
Discovery of the plot confirmed the fears of the intelligence agencies that Islamist groups had found a novel way to smuggle explosives into the cabin area in carry-on luggage after failed attempts with shoe bombs and explosives hidden in underwear. An explosion in a cabin (where a terrorist can position the explosive against a door or window) can have much more impact than one in the hold (where the terrorist has no control over the position of the explosive, which could be in the middle of luggage, away from the skin of the aircraft), given passengers and crew could be sucked out of any subsequent hole. - https://www.theguardian.com/world/2017/mar/26/plot-explosives-ipad-us-uk-laptop-ban
And not theoretical:
Somali authorities have released a video they say shows a laptop being given to the passenger after he has passed through the security checkpoint.
A man in an orange hi-vis vest is shown walking with a man in a blue shirt holding what looks like a laptop. Another man in a hat approaches them and it is alleged that the laptop is handed over. - http://www.bbc.com/news/world-africa-35521646
It *should* be far less painful to simply keep support around for it? It's not like keeping i686 support on an x86_64 distro is particularly hard, and with all the platform transition stuff that is in Apple's history, this is probably the easiest.
Hell, you could run pre-System 7 68k apps on PPC OS X systems 20 years later as a result of the Rosetta and Blue Box compatibility layers.
I really see this forced migration as a bit more of Apple's gradual decline. At one point, keeping all of these layers up and working would be seen as a point of pride and a welcome engineering challenge. Now the employees there seem just as caught up in the shiny/new as all the rest.
Epoxy is typically used to plug up ports. That's not a horrible idea restricting things to PS/2 keyboards and mice though... Certainly safer than letting badUSB load.
While interesting, and certainly providing confirmation, this wasn't the primary mechanism that was used to track her down according to the affidaivat. Before even IDing a specific printer, they simply looked for someone that had printed it out, period.
Internal auditing showed that only six employees had printed out the item in question. A search of the six computers showed that she had emailed The Intercept from her work computer (and that no one else had). Coded metadata just backs it up, but it's dumber than that.
The depth of ignorance displayed by systemd detractors is telling. You guys assumed that because you didn't know the reason why it exists, and that you know everything about Unix, therefore there was no reason for systemd and the developers were just doing this for no reason. In reality, every commercial Unix replaced sysvinit, because scripts relying on PID values are fundamentally a stupid idea.
I get the attraction of an OS that is all scripts, even if you're brain-damaged enough to think that Bash is a good language for that. I even get that there was a sweet spot in the 90s and early naughties where bash and perl and sysvinit were all the best tools for the job and complimented each other nicely. That era is over, and we have better tools now.
And you're missing the point completely (or haven't looked at a RedHat-style initscript in a while).
There's nothing inherent in the SysV Initscript interface that mandates the use of pid files. For many/most daemons that are reliable, that's probably good enough, but it doesn't have to be./sbin/service status, is just a call to a script. If there's something more involving service management that is a better mechanism than pid files than determining the state, so be it. (The killproc function RH provides in/etc/init.d/functions doesn't even use PID files by default unless provided one.) The point is, whatever it's doing to determine status a) has a well-defined interface (the script call), and b) is in most cases pretty simple and grokkable and *debuggable*, and not a bunch of complex C code.
Your larger point is begging the question, however. SysVInit is about starting services, not managing services (except to the extent it starts and stops things when switching runlevels). If you need realtime service babysitting, or on-demand forking, then you should use a system started by SysVInit that specializes in that. inet, xinetd, and a daemontools package (and even a systemd package focused solely on service management!) could all function this way, while still providing deterministic, script-driven startup and control for the things that don't need that layer of complexity. By combining/bin/init, rc system scripts, and service initscripts all into a single binary blob, it removed those interface layers and smooshed it all into a single one-size-fits-all black box.
I (and many others) would prefer the flexibility of being able to swap in control daemons without handing over control of my entire system to this monstrous blob.
If there's a better argument for anti-trust investigations against Google than this, then I can't think of it.
Google's search results are returning worse data (robots.txt respected) because the end result has decided not to rely on ad-supported (meaning: Google AdSense supported since they have a lion's share on the industry) content rather than the website doing whatever makes sense for itself, under the guise of the ever-ambiguous "user experience". This is not a some hacked, fly-by-night website altering content like it's 2002 again.
Google wants to index the world's information? Fine. Deciding its own policies on information retrieval and what business model it wants to promote? No bueno.
The security source said both bans were not the result of a single specific incident but a combination of factors. One of those, according to the source, was the discovery of a plot to bring down a plane with explosives hidden in a fake iPad that appeared as good as the real thing. Other details of the plot, such as the date, the country involved and the group behind it, remain secret. Discovery of the plot confirmed the fears of the intelligence agencies that Islamist groups had found a novel way to smuggle explosives into the cabin area in carry-on luggage after failed attempts with shoe bombs and explosives hidden in underwear. An explosion in a cabin (where a terrorist can position the explosive against a door or window) can have much more impact than one in the hold (where the terrorist has no control over the position of the explosive, which could be in the middle of luggage, away from the skin of the aircraft), given passengers and crew could be sucked out of any subsequent hole.
We tried that. If you recall, Bush campaigned on rolling back involvement in the Middle East and Europe (Clinton gave us Kosovo, if you recall) and to reduce nation-building abroad to focus on nation-building at home.
9/11 happened anyway.
To Bush's credit, he realized that his world-view had come face-to-face with reality and didn't stand the test, hence doing a 180 and deciding that the fight did indeed have to be taken to them after all.
Slashdot Mirror
50 miles west of Chicago, I get about 40 digital channels, most with perfect pictures from my attic antenna.
Free, but some channels are in Spanish and Polish !
The transition to digital was painless and good,
more channels, better picture.
I wouldn't exactly call it "painless", but probably overall a good thing.
I still feel like certain channel frequencies should have been left operational if only for public safety and emergency purposes. You do not need transistors to wire up a black-and-white analog signal television receiver.
The third problem is RPM. It's an antiquated package format. They should use APT instead. Then DNF can be discarded in favor of the APT tools. Problem solved.
Pretty sure you're trolling, but I do take issue with this. RPM is perfectly fine, especially compared to raw .dkpg (spec files are comprehensible, and the ability to have a %verifyscript alone is a major, major win)). In regards to apt, even yum (with its plugin ecosystem) had a number of benefits over apt-get and cousins. I'm no fan of DNF and still consider it to be a classic case of someone's pet project and pet API winning out solely because the conservatives yelling "stop" were looking away for a moment, but this is in line with all the other bone-headed things Fedora was doing around that time... :/
Top US General concerned about future job security. Worries the human element will soon not be a requirement when it comes to warfare.
This is a big deal in a country where War and Combat are glorified and have seeped into the facets of everyday life.
Lol. If you think "War" and "Combat" have seeped into everyday life in some countries, just wait till you live in a world without at least some amount of Pax Americana...
^ Mod parent up.
Additional dependencies = additional vulnerabilities, connotation partially intended
Good luck with that nowadays with police being more aggressive at picking up unaccompanied minors walking to and from the public library.
If you have a teen curfew in your area, take that up with your local city council. If you don't have a teen curfew in your area and that's happening, you might have bigger problems going on...
The information age began long before Nest or the iPhone. Also, the Nest is a piece of shit.
He's not talking about the information age, he's talking about constantly-available mobile data access to the information.
Kids (mostly nerdy kids) being stuck in front of a desktop computer a la the 90s and early 2000s is not the same thing as everyone glued to their smartphones 24/7, or tablets being used as pacifying devices from the age of toddlers on up.
Previous generations had similar problems. It's just they have forgotten about them. Spreading rumours? That happened with kids writing messages about each other and putting them on the school noticeboards. Rumours could spread simply by word of mouth without any need for Twitter, Facebook or IM. Teenagers would spend hours talking to each other by telephone.
You're missing the point. Just as the telephone (and long distance telephone) was an exponential leap in communication -- a communications revolution -- that drastically affected society, constant data interaction (the tipping point seemed to be smartphones with 4G-ish speeds) is ALSO an exponential leap.
The problem is that this second leap combines the mutliband communication power of the internet with the psychological attachment issues of a Skinner box, partly as a result of most of the Internet being funded by advertising dollars and sponsorship. Facebook, YouTube, and many other things wouldn't feel the need to be (quite) so addictive if they were simple subscription services instead of demographic tracking opportunities for selling micro-targeted ads.
Want more proof that it was a revolution? I'm hard-pressed to think of *any* science fiction stories or films of the 20th century that accurately predicted the psychological impact of always-on mobile data access that we're seeing now. Sure, plenty of stories imagined the technology (think Star Trek TNG's PADD's, etc), but no one seems to have predicted the impact on human sociology that we're already seeing. It wasn't expected.
Many people turned the other way, trusting that RH (which had just seamlessly switched from traditional init to upstart in the previous release) wouldn't do anything particularly dumb. We were wrong. Or we assumed that Fedora's community would self-correct.
All through the F14 and F15 release cycles concerns were raised as feature and scope creep began to set in (even then). Many people "knew it would (likely) suck" because things were getting out of hand (and they remembered how LP had screwed up PulseAudio) and spoke up about it.
Possibly also SELinux problems. I've seen policy problems silently freeze startup for no reason that were quite tricky to resolve. And a policy rollback in RHEL7.1 ended with me wiping and rebuilding the box.
"Making unit files more portable" is a euphemism for "enforcing our standard on other systems and distributions".
If "0day" is a valid user on a system, there's absolutely ZERO reason why "User=0day" shouldn't be valid config on a system management tool (let alone an init replacement) that runs on that system. I don't care what other distributions do.
LP, once again, shows us that he thinks "Doesn't work on anything except my laptop with my particular setup" is a feature, not a bug, for middleware he's snuck into every distro out there.
Tarring and feathering is quite appropriate.
The problem isn't the operating system. On most computers, time_t is a 64 bit value, even on 32 bit machines.
What? Are you a Millennial?
Holy shit, it's like we've forgotten about the major privacy implications of the first version of this: Google Desktop
Sure it can. Have you seen what demo makers can do with procedural generation?
Something that does a best-effort analog to digital conversion into equations and not samples would "compress down" that much because you're not really compressing at all, but re-creating from scratch into something approximating what was there. Think of an automated MOD/trakker creator.
Funny thing is she did not get arrested by Trump or the administration but by the FBI. When you break the law it is law enforcement that comes after you. If you listen to this kind of headline you would think that Trump had singled her out or something.
The FBI is part of the Executive Branch. Perhaps you missed that part in civics class.
So... The bomb goes off in the hold and starts a fire? Jets don't usually recover from that... At least up top, you might confine the damage to a hole next to whoever has the laptop bomb (Egypt Air...)
Jets possibly can recover from that, depending on placement and how reinforced the baggage hold is.
Jets can't recover from sudden depressurization via gaping hole in the cabin. The only reason the Daallo Airlines flight in Somalia wasn't worse was because the bomb next to the window went off before they had reached cruising altitude and the cabin was pressurized.
Not so vague:
And not theoretical:
But sure... keep complaining.
The original threat was an iPad, so anything roughly that size that could have explosives placed in there would probably be the limit.
Phablets? Maybe... Tablets and laptops, almost certainly.
See also: http://www.bbc.com/news/world-africa-35521646
It *should* be far less painful to simply keep support around for it? It's not like keeping i686 support on an x86_64 distro is particularly hard, and with all the platform transition stuff that is in Apple's history, this is probably the easiest.
Hell, you could run pre-System 7 68k apps on PPC OS X systems 20 years later as a result of the Rosetta and Blue Box compatibility layers.
I really see this forced migration as a bit more of Apple's gradual decline. At one point, keeping all of these layers up and working would be seen as a point of pride and a welcome engineering challenge. Now the employees there seem just as caught up in the shiny/new as all the rest.
Epoxy is typically used to plug up ports. That's not a horrible idea restricting things to PS/2 keyboards and mice though... Certainly safer than letting badUSB load.
While interesting, and certainly providing confirmation, this wasn't the primary mechanism that was used to track her down according to the affidaivat. Before even IDing a specific printer, they simply looked for someone that had printed it out, period.
Internal auditing showed that only six employees had printed out the item in question. A search of the six computers showed that she had emailed The Intercept from her work computer (and that no one else had). Coded metadata just backs it up, but it's dumber than that.
The depth of ignorance displayed by systemd detractors is telling. You guys assumed that because you didn't know the reason why it exists, and that you know everything about Unix, therefore there was no reason for systemd and the developers were just doing this for no reason. In reality, every commercial Unix replaced sysvinit, because scripts relying on PID values are fundamentally a stupid idea.
I get the attraction of an OS that is all scripts, even if you're brain-damaged enough to think that Bash is a good language for that. I even get that there was a sweet spot in the 90s and early naughties where bash and perl and sysvinit were all the best tools for the job and complimented each other nicely. That era is over, and we have better tools now.
And you're missing the point completely (or haven't looked at a RedHat-style initscript in a while).
There's nothing inherent in the SysV Initscript interface that mandates the use of pid files. For many/most daemons that are reliable, that's probably good enough, but it doesn't have to be. /sbin/service status, is just a call to a script. If there's something more involving service management that is a better mechanism than pid files than determining the state, so be it. (The killproc function RH provides in /etc/init.d/functions doesn't even use PID files by default unless provided one.) The point is, whatever it's doing to determine status a) has a well-defined interface (the script call), and b) is in most cases pretty simple and grokkable and *debuggable*, and not a bunch of complex C code.
Your larger point is begging the question, however. SysVInit is about starting services, not managing services (except to the extent it starts and stops things when switching runlevels). If you need realtime service babysitting, or on-demand forking, then you should use a system started by SysVInit that specializes in that. inet, xinetd, and a daemontools package (and even a systemd package focused solely on service management!) could all function this way, while still providing deterministic, script-driven startup and control for the things that don't need that layer of complexity. By combining /bin/init, rc system scripts, and service initscripts all into a single binary blob, it removed those interface layers and smooshed it all into a single one-size-fits-all black box.
I (and many others) would prefer the flexibility of being able to swap in control daemons without handing over control of my entire system to this monstrous blob.
The depressing thing is thinking back to how many Millennials have never used a Spatial Finder at all... like ever.
*sigh* They probably don't remember Sad Mac icons either :(
Yes, get off my lawn.
If there's a better argument for anti-trust investigations against Google than this, then I can't think of it.
Google's search results are returning worse data (robots.txt respected) because the end result has decided not to rely on ad-supported (meaning: Google AdSense supported since they have a lion's share on the industry) content rather than the website doing whatever makes sense for itself, under the guise of the ever-ambiguous "user experience". This is not a some hacked, fly-by-night website altering content like it's 2002 again.
Google wants to index the world's information? Fine. Deciding its own policies on information retrieval and what business model it wants to promote? No bueno.
This has been my suspicion, though I've yet to see anything official to support my suspicion.
What, you don't trust Slashdot?
We tried that. If you recall, Bush campaigned on rolling back involvement in the Middle East and Europe (Clinton gave us Kosovo, if you recall) and to reduce nation-building abroad to focus on nation-building at home.
9/11 happened anyway.
To Bush's credit, he realized that his world-view had come face-to-face with reality and didn't stand the test, hence doing a 180 and deciding that the fight did indeed have to be taken to them after all.