Deep packet inspection can turn up lots of easily identifiable behavior. Port scrambling, intentional service misidentification, mixing bogus streams with encrypted ones, bursting traffic over multiple IPv6s, all can make a difference.
But an ssh link is easily identifiable. They don't have to read anything, just block stuff. Experience as a teacher, 100% of what you do gets seen; what goes through is an algorithm that changes as they like it to.
They'll perform one block, but it seems tough for them to have lots of blocks running concurrently. Cat and mouse, and it'll be that way for the foreseeable future.
I use Zimbra as a pre-burned VM from TurnKeyLinux.com. They supply it in four formats, including an ISO and VMDK. You can also setup the VM from VMWare's latest cut of Zimbra as well. It does IMAP, POP, to various offline readers, calendar, and is moderately intelligent.
And the TKL version is free; VMware has a closed/commercial and open version available. If you've had even nominal email client/server setup experience, you can make it work in short order. It uses a web app, and has been solid in my experience (4yrs).
There were several forms of networking over twisted pair in the 80s. StarLan, AppleTalk, even twisted-pair ARCNet used early Bell cable. LattisNet was proposed, but the IEEE committee wisely chose 10BaseT in '87.
The need for higher speeds prompted examining the TSB-67 to come up with what was then Cat 4, and Cat 5. Cat 5 took off quickly, and because there were other strange things that worked with Cat 5, became the default until various "enhanced" schemes that could tolerate the biggest problem-- the modular adapter-- became standardized.
I've put in plenty of coax, thick, thin, and twisted pairs of many grades. Some of that stuff is still deployed-- the coax and 10BaseT, because it never needed to be changed. Lots of other stuff was ripped out or replaced.
You're diligent whatever it is. All of them can get pounded to the point where something will break, and you get rooted, or slipped with bit of nastyware. All of them.
You do what you're supposed to do: protect each machine as though it were an island. Use authentication that has reasonable key exchange. Stay off "hotspots" that don't use WPA or stronger keys. Backup. There are entire college degrees based on the question you ask.
A friend is a kernel contributor. Early on, one of my routines, now long gone, was in there. The process is familiar. This is the kernel. Like other kernels, it has numerous kinds of users. Some are adept, some are not, and some are accident free, while others are prone to it.
Cleaning machines daily of malware doesn't have to happen at all, no matter the OS. The ability to inhibit malware and virus infection vectors is at hand for most all platforms (I'll leave out exceptions, to reduce a flame war).
Email messages become more and more clever at inducing users to click on stuff. What's there when they arrive? Maybe it's a benign ED drug site. Maybe they're about to get a big gulp of crap. Lock downs, as you cite, have varying degrees of helpfulness. OSes need seat belts, air bags, and other metaphorical help. I don't find any of them particularly immune, although I like the design of IPFW, and SELinux for session management-- where that's practical in a client/server environment. On user hardware, presume an infected OS, no matter the type. Android, in my mind, is as bad as iOS, although I like APNS lockdowns. But people root phones all the time, and some of the MDM software out there barely sends up a red flag. Are roots inherently evil? Any organization has to consider them a problem, because they're an infection vector and payload provider.
Believing that Linux is less vulnerable is onerous because it will lead to sloth. One less thing to worry about, or so it would seem. Then, like me, you can get your primary httpd site taken down in a heartbeat to become part of a bot'd torrent network temporary C&C server. Fortunately, the AC plug was nearby.
I use Linux, and I used to agree with some of your platitudes, but not any more.
Although you believe that the community isn't trying to hide the flaws, most users didn't compile squat on their machines. They didn't look at the code, and although some are indeed coders, there are now millions of lines of code that change *a lot*. There's the kernel, in many revisions, and there are apps and distro families that change/mutate frequently and not very many people look at the code before they compile it and go Oh! There's a problem there! They may look at best, as a forensic exercise, long after they downloaded a replacement app, but that's about it.
Yes, there are wonderful kernel contributors and many fantastic FOSS sites and apps and distros. Only a handful of organizations try and keep it together-- at all.
"Found and fixed quickly" is largely a myth. Some communities really work hard towards fixing bugs, but there are many platforms and combinations needed to emulate problems. Coders move on, communities split, fork, or just die of boredom. There are no guarantees in either commercial or FOSS software.
And having been hacked hard twice, I can tell you that you can be rooted in moments, your machine hijacked, and unavailable to a user session no matter what OS you use. With a big enough hammer, you can break *anything*. The smugness is unwarranted.
Not broken, but not predictable. There are no standards, one vehicle to the next. If you live in an outlying area to a metropolitan area, your signal strength for any particular station is somewhat dubious. Click to the next one, and whoops-- might not be strong enough to latch the phase lock loop in the receiver, and so it'll skip it. Maybe you landed on the one you thought, maybe not. Maybe you have several bands, and let's say FM1,2,&3 where there are now 18 selections instead of the six that might be depressed on a console. Sometimes you'll remember what they are, but often not, and you'll look at the console.
Volume prediction is strange, too. I get about 3db when I ride in a Mini, but a Hyundai is much softer. That you have predictability is great, but not everyone does. Take a few more samples and ask about how often people using wheel-mounted controls go back to the console visually or manually, and why. You'll get more data, and fewer WTFs.
Then there are the steering wheel-mounted controls for audio/radio controls with are about as useless and perhaps as dangerous as the touch screen. Yes, you'd think-- great! Don't have to take my eyes off the road, but the controlled device, media player or radio, isn't quite so smart, so your eyes are taken off the road, hand off the wheel to make adjustments because the device skipped a station, or didn't rollover to the next band, etc. Added points for the bluetooth interface that is supposed to be hand-free, but isn't, really.
It's the latest trend and meme to remove it, or reduce it, or vilify it. Your post has already been down-modded, an indicator of the irrational vehemence.
The price of the machine wasn't jacked up because of the TrialWare, but the price seems unreasonably high, given so much competition at a lower price.
The extra software gives the machine perceived value, incorrect as that may be. Lots of trialware that won't last long and makes revenues for everyone not-the-retailer.
But then, the latest loads of Ubuntu have all sorts of crazyware, albeit not in the trial form. There are legacy Unix/Linux sillyness that most consumers will never, ever touch. No one pays an OEM to put it on a machine (oh, wait, Amazon placement for search???) when Linux is installed, but most every page you access these days has some sort of ad, or tracker, or link-to-a-good-buddy.
If you'd read the link inside post, you'd see that the citations were already there, and Google and DDG are both represented by quotes.
They're not lazy at all. Instead, the post was used to craft a reactive opinion based on only a few facts inside the referenced link so as to provoke a response. This is called: suckerbait, and many took it.
Should search engine choice be the same number of clicks? Perhaps. But what the article alludes to is that a preponderance of facts *appears* that Google is engaged in anti-competitive behavior. Whether that behavior is monopolistic or sufficiently injures the public so as to motivate FTC litigation is still unknown.
Is DDG crying empty tears? I think they have some legitimate beefs with Google. I believe that Google is anti-competitive, but I don't know whether they're sufficiently anti-competitive so as to necessitate action to control that behavior. A good fight is a good fight until someone's fighting "dirty".
The problem is also with the classical Von Neumann model of the state machine. You can have many nodes that do work, then sync-up at different points as dependencies on a JCL- like program. When you have common nodes running at CPU clock, then the amount of buffer and cache that gets dirty is small, and the sync-time is the largest common denominator amongst the calculating nodes. When you bust that model by having an error in one or more nodes, then the sync can't happen until the last node is caught up. Other non-dependent functions can continue, but at some point, it grinds to a halt waiting either the initial node to complete, or for a replacement to complete, but completion nonetheless.
When you run asynchronous jobs, the cycle time becomes less dependent on node failure, but more dependent on a competent coder's error handler that knows how to react, and spawns whatever's necessary to bring about an appropriate reaction to a node failure whilst keeping the rest of the jobs humming along.
I think ZFS was a great start to having large data sets operated on by concurrent objective code sets, but tightly coupled systems are a recipe for disaster because of their state-machine fragility.
We disagree. Rich or poor, people have to breathe. They need shelter. The contributions to mitigating the problems need to be found and implemented no matter where they occur, here, there, anywhere.
I'm the future generation. I have a grandson due in March. It's not an abstract idea. There will be no zombie apocalypse. There will be children.
Maybe we're the generation that realized through scientific discovery, that there are limitations to resources. Maybe we took responsibility for our actions, rather than blithely ignoring the warning signs.
Wealth creation is a long tried and true, but ultimately vacuous destination. Maybe we sacrifice a little as a world community and benefit greatly from having done so, rather than hedonistically building wads of cash and grandiose castles.
War is not inevitable. Those that believe this often use it as an excuse to behave badly and cowardly rather than face up to the fact that we all live on this planet together. Degrading the economy will be laughable in the face of not being able to breathe, with shorelines starting in the Rockies and Appalachia.
Lots of work to be done. International ship exhaust is unbelievably, even insanely high and totally unregulated. We have lots of "clean coal" to replace, along with the jobs that'll be lost. One mountain at a time....
If you don't believe that you need to think seriously about your own personal contributions to the problem, then you rob future generations by your sloth.
There will be all sorts of methods, some that work, some that are insane and don't work, but I appreciate California trying to tackle the problem. With hard work, the California example will help mitigate the problem and raise understanding of how to make it work.
Upthread, it was posited that if you brought down LTE, you might bring down public safety response as well. Many units use freq-hopping devices that are somewhat immune to specific (or many) channel jamming. Although there is a bit of this in LTE, the attacks purported are more infrastructure attacks than broad-spectra/channel-specific attacks. The infrastructure melts, metaphorically speaking.
With FSK radios, attacking the radio is useless, unless you attack all of the F(reqs) used by the FSK radios. You can slow them down, but like Bluetooth, they're tough to stop.
If you get LTE connects, you can do an attack that looks like a TCP SYN attack, creating sessions until none are available, unless there is a defense against the TTL life of the TCP connect. This is an infrastructure attack (one of several theoretically possible). If you think like a DDoS artist does, the rest is simple. But I'm not going to teach you. And I'm purposefully omitting specific details.
I'll imagine that LTE freqs won't the the only one being jammed if something actually does happen. Doesn't take much to do jamming effectively, and only broad frequency-hopping stuff is truly immune.
Slashdot Mirror
Deep packet inspection can turn up lots of easily identifiable behavior. Port scrambling, intentional service misidentification, mixing bogus streams with encrypted ones, bursting traffic over multiple IPv6s, all can make a difference.
But an ssh link is easily identifiable. They don't have to read anything, just block stuff. Experience as a teacher, 100% of what you do gets seen; what goes through is an algorithm that changes as they like it to.
They'll perform one block, but it seems tough for them to have lots of blocks running concurrently. Cat and mouse, and it'll be that way for the foreseeable future.
The folly is: you thought you had control in the first place.
I use Zimbra as a pre-burned VM from TurnKeyLinux.com. They supply it in four formats, including an ISO and VMDK. You can also setup the VM from VMWare's latest cut of Zimbra as well. It does IMAP, POP, to various offline readers, calendar, and is moderately intelligent.
And the TKL version is free; VMware has a closed/commercial and open version available. If you've had even nominal email client/server setup experience, you can make it work in short order. It uses a web app, and has been solid in my experience (4yrs).
There were several forms of networking over twisted pair in the 80s. StarLan, AppleTalk, even twisted-pair ARCNet used early Bell cable. LattisNet was proposed, but the IEEE committee wisely chose 10BaseT in '87.
The need for higher speeds prompted examining the TSB-67 to come up with what was then Cat 4, and Cat 5. Cat 5 took off quickly, and because there were other strange things that worked with Cat 5, became the default until various "enhanced" schemes that could tolerate the biggest problem-- the modular adapter-- became standardized.
I've put in plenty of coax, thick, thin, and twisted pairs of many grades. Some of that stuff is still deployed-- the coax and 10BaseT, because it never needed to be changed. Lots of other stuff was ripped out or replaced.
You're diligent whatever it is. All of them can get pounded to the point where something will break, and you get rooted, or slipped with bit of nastyware. All of them.
You do what you're supposed to do: protect each machine as though it were an island. Use authentication that has reasonable key exchange. Stay off "hotspots" that don't use WPA or stronger keys. Backup. There are entire college degrees based on the question you ask.
A friend is a kernel contributor. Early on, one of my routines, now long gone, was in there. The process is familiar. This is the kernel. Like other kernels, it has numerous kinds of users. Some are adept, some are not, and some are accident free, while others are prone to it.
Cleaning machines daily of malware doesn't have to happen at all, no matter the OS. The ability to inhibit malware and virus infection vectors is at hand for most all platforms (I'll leave out exceptions, to reduce a flame war).
Email messages become more and more clever at inducing users to click on stuff. What's there when they arrive? Maybe it's a benign ED drug site. Maybe they're about to get a big gulp of crap. Lock downs, as you cite, have varying degrees of helpfulness. OSes need seat belts, air bags, and other metaphorical help. I don't find any of them particularly immune, although I like the design of IPFW, and SELinux for session management-- where that's practical in a client/server environment. On user hardware, presume an infected OS, no matter the type. Android, in my mind, is as bad as iOS, although I like APNS lockdowns. But people root phones all the time, and some of the MDM software out there barely sends up a red flag. Are roots inherently evil? Any organization has to consider them a problem, because they're an infection vector and payload provider.
Believing that Linux is less vulnerable is onerous because it will lead to sloth. One less thing to worry about, or so it would seem. Then, like me, you can get your primary httpd site taken down in a heartbeat to become part of a bot'd torrent network temporary C&C server. Fortunately, the AC plug was nearby.
I use Linux, and I used to agree with some of your platitudes, but not any more.
Although you believe that the community isn't trying to hide the flaws, most users didn't compile squat on their machines. They didn't look at the code, and although some are indeed coders, there are now millions of lines of code that change *a lot*. There's the kernel, in many revisions, and there are apps and distro families that change/mutate frequently and not very many people look at the code before they compile it and go Oh! There's a problem there! They may look at best, as a forensic exercise, long after they downloaded a replacement app, but that's about it.
Yes, there are wonderful kernel contributors and many fantastic FOSS sites and apps and distros. Only a handful of organizations try and keep it together-- at all.
"Found and fixed quickly" is largely a myth. Some communities really work hard towards fixing bugs, but there are many platforms and combinations needed to emulate problems. Coders move on, communities split, fork, or just die of boredom. There are no guarantees in either commercial or FOSS software.
And having been hacked hard twice, I can tell you that you can be rooted in moments, your machine hijacked, and unavailable to a user session no matter what OS you use. With a big enough hammer, you can break *anything*. The smugness is unwarranted.
Naw.
We just spin up a few dozen machines at AWS, split up the crack load among the, pop your key, and move on to the next twit. /sarcasm
Not broken, but not predictable. There are no standards, one vehicle to the next. If you live in an outlying area to a metropolitan area, your signal strength for any particular station is somewhat dubious. Click to the next one, and whoops-- might not be strong enough to latch the phase lock loop in the receiver, and so it'll skip it. Maybe you landed on the one you thought, maybe not. Maybe you have several bands, and let's say FM1,2,&3 where there are now 18 selections instead of the six that might be depressed on a console. Sometimes you'll remember what they are, but often not, and you'll look at the console.
Volume prediction is strange, too. I get about 3db when I ride in a Mini, but a Hyundai is much softer. That you have predictability is great, but not everyone does. Take a few more samples and ask about how often people using wheel-mounted controls go back to the console visually or manually, and why. You'll get more data, and fewer WTFs.
Then there are the steering wheel-mounted controls for audio/radio controls with are about as useless and perhaps as dangerous as the touch screen. Yes, you'd think-- great! Don't have to take my eyes off the road, but the controlled device, media player or radio, isn't quite so smart, so your eyes are taken off the road, hand off the wheel to make adjustments because the device skipped a station, or didn't rollover to the next band, etc. Added points for the bluetooth interface that is supposed to be hand-free, but isn't, really.
as described by Reuters at http://www.reuters.com/article/2012/11/27/us-amd-blackfriday-idUSBRE8AQ12I20121127
Well, you were wondering, right?
It's the latest trend and meme to remove it, or reduce it, or vilify it. Your post has already been down-modded, an indicator of the irrational vehemence.
The price of the machine wasn't jacked up because of the TrialWare, but the price seems unreasonably high, given so much competition at a lower price.
The extra software gives the machine perceived value, incorrect as that may be. Lots of trialware that won't last long and makes revenues for everyone not-the-retailer.
But then, the latest loads of Ubuntu have all sorts of crazyware, albeit not in the trial form. There are legacy Unix/Linux sillyness that most consumers will never, ever touch. No one pays an OEM to put it on a machine (oh, wait, Amazon placement for search???) when Linux is installed, but most every page you access these days has some sort of ad, or tracker, or link-to-a-good-buddy.
I think the crapware complaint is over-rated.
If you'd read the link inside post, you'd see that the citations were already there, and Google and DDG are both represented by quotes.
They're not lazy at all. Instead, the post was used to craft a reactive opinion based on only a few facts inside the referenced link so as to provoke a response. This is called: suckerbait, and many took it.
Should search engine choice be the same number of clicks? Perhaps. But what the article alludes to is that a preponderance of facts *appears* that Google is engaged in anti-competitive behavior. Whether that behavior is monopolistic or sufficiently injures the public so as to motivate FTC litigation is still unknown.
Is DDG crying empty tears? I think they have some legitimate beefs with Google. I believe that Google is anti-competitive, but I don't know whether they're sufficiently anti-competitive so as to necessitate action to control that behavior. A good fight is a good fight until someone's fighting "dirty".
I am not accountable to you; no other answers will be forthcoming now, or in the future.
You should care about future generations because we're all in this together.
You are a troll, sir. And not a very good one.
The problem is also with the classical Von Neumann model of the state machine. You can have many nodes that do work, then sync-up at different points as dependencies on a JCL- like program. When you have common nodes running at CPU clock, then the amount of buffer and cache that gets dirty is small, and the sync-time is the largest common denominator amongst the calculating nodes. When you bust that model by having an error in one or more nodes, then the sync can't happen until the last node is caught up. Other non-dependent functions can continue, but at some point, it grinds to a halt waiting either the initial node to complete, or for a replacement to complete, but completion nonetheless.
When you run asynchronous jobs, the cycle time becomes less dependent on node failure, but more dependent on a competent coder's error handler that knows how to react, and spawns whatever's necessary to bring about an appropriate reaction to a node failure whilst keeping the rest of the jobs humming along.
I think ZFS was a great start to having large data sets operated on by concurrent objective code sets, but tightly coupled systems are a recipe for disaster because of their state-machine fragility.
We disagree. Rich or poor, people have to breathe. They need shelter. The contributions to mitigating the problems need to be found and implemented no matter where they occur, here, there, anywhere.
How is it done? We're learning how.
Except for fuel reformulation, and the actions of various AQMD, this is a start.
You weasel my words.
I'm the future generation. I have a grandson due in March. It's not an abstract idea. There will be no zombie apocalypse. There will be children.
Maybe we're the generation that realized through scientific discovery, that there are limitations to resources. Maybe we took responsibility for our actions, rather than blithely ignoring the warning signs.
Wealth creation is a long tried and true, but ultimately vacuous destination. Maybe we sacrifice a little as a world community and benefit greatly from having done so, rather than hedonistically building wads of cash and grandiose castles.
War is not inevitable. Those that believe this often use it as an excuse to behave badly and cowardly rather than face up to the fact that we all live on this planet together. Degrading the economy will be laughable in the face of not being able to breathe, with shorelines starting in the Rockies and Appalachia.
Lots of work to be done. International ship exhaust is unbelievably, even insanely high and totally unregulated. We have lots of "clean coal" to replace, along with the jobs that'll be lost. One mountain at a time....
A glib and superficial comment at best.
If you don't believe that you need to think seriously about your own personal contributions to the problem, then you rob future generations by your sloth.
There will be all sorts of methods, some that work, some that are insane and don't work, but I appreciate California trying to tackle the problem. With hard work, the California example will help mitigate the problem and raise understanding of how to make it work.
You know, those ST-225s from Seagate cost a lot of $$$ these days.
Why waste power? There are good defenses. But......
Upthread, it was posited that if you brought down LTE, you might bring down public safety response as well. Many units use freq-hopping devices that are somewhat immune to specific (or many) channel jamming. Although there is a bit of this in LTE, the attacks purported are more infrastructure attacks than broad-spectra/channel-specific attacks. The infrastructure melts, metaphorically speaking.
With FSK radios, attacking the radio is useless, unless you attack all of the F(reqs) used by the FSK radios. You can slow them down, but like Bluetooth, they're tough to stop.
If you get LTE connects, you can do an attack that looks like a TCP SYN attack, creating sessions until none are available, unless there is a defense against the TTL life of the TCP connect. This is an infrastructure attack (one of several theoretically possible). If you think like a DDoS artist does, the rest is simple. But I'm not going to teach you. And I'm purposefully omitting specific details.
I'll imagine that LTE freqs won't the the only one being jammed if something actually does happen. Doesn't take much to do jamming effectively, and only broad frequency-hopping stuff is truly immune.
Oh, wait.....