 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/31/2013 10:50 AM, Jim Henderson wrote:
> On Tue, 27 Aug 2013 18:19:45 +0100, Orchid Win7 v1 wrote:
>
>> What I *do* have an issue with is MS deciding that *I* can't get stuff
>> done with my own PC because "most" end-users don't need that feature.
>
> Such as?
>
> Jim
>
Hmm. How about - "Without hunting down some third party tool to do it."?
Though, some things the OS just won't let you do at all. Like, well,
nearly any tool used to test network issues is "throttled", as in, in
this case, "strangled" by the "protections" added, to prevent certain
types of packets, which "might" be from a virus/worm/botnet. I am sure
you could, somehow, if you wanted to spend stupid amounts of time
hunting for a solution, find a way to turn that off, maybe...
Or, there is the real good one, like.. trying to install HP
multi=function printer drivers, and finding that, and MS, their scanner,
and even other virus scanners, will all argue, "Its somehow HPs fault,
not us!", the scanner software itself won't install properly, since it
uses some funcky packet talk, even over USB, which "modern" virus
scanners, and firewalls, etc. including the stuff made by MS, all
trigger on, and cause to fail. For some damn reason, apparently, not
having the virus scanner, etc. "on" at the time you install this may fix
it, maybe, if you are lucky, but.. you can't fix the existing install,
no matter what you do, short of pulling the plug on the whole printer
driver suite, and, maybe, again, reinstalling, with your PC wide open to
the very attacks that you are supposed to use the stuff to stop.
So, yeah, I do blame HP for thinking this idiocy was a good idea (I
think what they did was run the same protocol via USB as they do over
the network, somehow, so it fucks up both ways, even with a direct
connection, but still.. Why the hell should it even happen at all, never
mind be, literally, unrepairable?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 31 Aug 2013 19:00:22 -0700, Patrick Elliott wrote:
> Hmm. How about - "Without hunting down some third party tool to do it."?
That might have been a good qualifier to add, yes.
> Though, some things the OS just won't let you do at all. Like, well,
> nearly any tool used to test network issues is "throttled", as in, in
> this case, "strangled" by the "protections" added, to prevent certain
> types of packets, which "might" be from a virus/worm/botnet. I am sure
> you could, somehow, if you wanted to spend stupid amounts of time
> hunting for a solution, find a way to turn that off, maybe...
Haven't run into that one.
> Or, there is the real good one, like.. trying to install HP
> multi=function printer drivers, and finding that, and MS, their scanner,
> and even other virus scanners, will all argue, "Its somehow HPs fault,
> not us!", the scanner software itself won't install properly, since it
> uses some funcky packet talk, even over USB, which "modern" virus
> scanners, and firewalls, etc. including the stuff made by MS, all
> trigger on, and cause to fail. For some damn reason, apparently, not
> having the virus scanner, etc. "on" at the time you install this may fix
> it, maybe, if you are lucky, but.. you can't fix the existing install,
> no matter what you do, short of pulling the plug on the whole printer
> driver suite, and, maybe, again, reinstalling, with your PC wide open to
> the very attacks that you are supposed to use the stuff to stop.
>
> So, yeah, I do blame HP for thinking this idiocy was a good idea (I
> think what they did was run the same protocol via USB as they do over
> the network, somehow, so it fucks up both ways, even with a direct
> connection, but still.. Why the hell should it even happen at all, never
> mind be, literally, unrepairable?
That's not really an OS issue, though. That's an HP issue, as
described. I don't think you can blame Microsoft for HP's bad design
decision.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/09/2013 2:51 AM, Patrick Elliott wrote:
> On 8/31/2013 12:35 AM, Stephen wrote:
>>
>>
>> Yes, well. Just think of it as junk DNA or a bit of history. :-)
>>
> Snort.. So.. all the smart, better, tools got caught in a flash flood,
> and are now, at best, fossilized, while the slow, stupid ones, which
> never made it into the river bed, before the flood hit, kept breeding...
> Yeah, that sounds about right. lol
As long as you can keep your sense of humour. All is not lost.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/31/2013 7:23 PM, Jim Henderson wrote:
> On Sat, 31 Aug 2013 19:00:22 -0700, Patrick Elliott wrote:
>
>> Hmm. How about - "Without hunting down some third party tool to do it."?
>
> That might have been a good qualifier to add, yes.
>
>> Though, some things the OS just won't let you do at all. Like, well,
>> nearly any tool used to test network issues is "throttled", as in, in
>> this case, "strangled" by the "protections" added, to prevent certain
>> types of packets, which "might" be from a virus/worm/botnet. I am sure
>> you could, somehow, if you wanted to spend stupid amounts of time
>> hunting for a solution, find a way to turn that off, maybe...
>
> Haven't run into that one.
>
Well. It was, in my case, an attempt to get around the stupid decision
of my neighbors ISP to block control packets on their modems, so that,
when there was a problem, you couldn't use tracert, or ping, to check if
the problem was some place in their network, or if the modem needed to
be powered down, and back on, or something. So, I tried, instead, on my
own machine, to run one that generates the same thing, using regular
TCP/IP. But, since the packets where set to have odd timeouts, and
contain very little actually "data", the new safeguards flagged them as
possible DOS traffic, and simply killed them, without ever sending them.
> That's not really an OS issue, though. That's an HP issue, as
> described. I don't think you can blame Microsoft for HP's bad design
> decision.
>
> Jim
>
Its more of a "layering" issue. The firewall can block some things, the
virus scanner others, the HP software is assuming that neither of these
things are going to be in the way, and.. as near as I can tell, it works
fine, if, for example, you are running it wireless, or connected "to"
the router. But, then they got lazy and figured, "Heck, why not connect
it to the USB using the same thing." Then.. everything gets in the way,
including an OS that pretty much won't let you find/figure out/fix
problems like this, by actually knowing where the bloody
driver/settings, etc. might all be, so you can, I don't know.. manually
edit settings, if you had to? :p So, yeah. It might be an HP problem,
but its an HP problem that, if it was easy to fix, they had like 3-4
years, since they started using this method to get the things to talk to
each other, to actually put out a bug fix for, and haven't. Which,
usually, means the OS is making assumptions that are keeping them from
reliably fixing it.
Mind, I know this was a poor example. But, I also know that there are
situations that *definitely* ended up being the OS in the way, entirely,
not just some other companies buggy installer. And, again, when things
do go wrong.. Its not like you can throw tests at it, from a command
line, or from a basic script, or anything else you might do, to see what
the frak is really going on. All the OS will tell you is, "This looks
like its working, because the driver says so, I don't know why the fuck
it crashes 1/3 of the way into a scan!", or the like. I would hardly
call that "working"...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 01 Sep 2013 19:54:21 -0700, Patrick Elliott wrote:
>> Haven't run into that one.
>>
> Well. It was, in my case, an attempt to get around the stupid decision
> of my neighbors ISP to block control packets on their modems, so that,
> when there was a problem, you couldn't use tracert, or ping, to check if
> the problem was some place in their network, or if the modem needed to
> be powered down, and back on, or something. So, I tried, instead, on my
> own machine, to run one that generates the same thing, using regular
> TCP/IP. But, since the packets where set to have odd timeouts, and
> contain very little actually "data", the new safeguards flagged them as
> possible DOS traffic, and simply killed them, without ever sending them.
Sounds like ISP interference to me rather than the OS, though.
> Its more of a "layering" issue. The firewall can block some things, the
> virus scanner others, the HP software is assuming that neither of these
> things are going to be in the way, and.. as near as I can tell, it works
> fine, if, for example, you are running it wireless, or connected "to"
> the router. But, then they got lazy and figured, "Heck, why not connect
> it to the USB using the same thing." Then.. everything gets in the way,
> including an OS that pretty much won't let you find/figure out/fix
> problems like this, by actually knowing where the bloody
> driver/settings, etc. might all be, so you can, I don't know.. manually
> edit settings, if you had to? :p So, yeah. It might be an HP problem,
> but its an HP problem that, if it was easy to fix, they had like 3-4
> years, since they started using this method to get the things to talk to
> each other, to actually put out a bug fix for, and haven't. Which,
> usually, means the OS is making assumptions that are keeping them from
> reliably fixing it.
Given the complexity of modern software, it's kinda difficult to predict
every contingency and plan for it.
HP isn't exactly known for being proactive in how they do things. And as
good as their printers are, their printer driver installation routines
have always been crap. It /would/ be nice if MS standardized driver
installations across different platforms (hey, remember, I used to work
for Novell and had more than a few discussions with people about iPrint-
based printer driver installation, and it was /always/ more complicated
than it needed to be because MS made it so difficult to do in a standard
way).
> Mind, I know this was a poor example. But, I also know that there are
> situations that *definitely* ended up being the OS in the way, entirely,
> not just some other companies buggy installer. And, again, when things
> do go wrong.. Its not like you can throw tests at it, from a command
> line, or from a basic script, or anything else you might do, to see what
> the frak is really going on. All the OS will tell you is, "This looks
> like its working, because the driver says so, I don't know why the fuck
> it crashes 1/3 of the way into a scan!", or the like. I would hardly
> call that "working"...
Would that all operating system software were bug- and trouble- free. :)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/1/2013 9:02 PM, Jim Henderson wrote:
> On Sun, 01 Sep 2013 19:54:21 -0700, Patrick Elliott wrote:
>
>>> Haven't run into that one.
>>>
>> Well. It was, in my case, an attempt to get around the stupid decision
>> of my neighbors ISP to block control packets on their modems, so that,
>> when there was a problem, you couldn't use tracert, or ping, to check if
>> the problem was some place in their network, or if the modem needed to
>> be powered down, and back on, or something. So, I tried, instead, on my
>> own machine, to run one that generates the same thing, using regular
>> TCP/IP. But, since the packets where set to have odd timeouts, and
>> contain very little actually "data", the new safeguards flagged them as
>> possible DOS traffic, and simply killed them, without ever sending them.
>
> Sounds like ISP interference to me rather than the OS, though.
>
But, its not. There are a fair number of servers that, for security
reasons, may disable the control packets, including routers in the
primary backbones of the internet (or alternate paths). This means that
tracing a problem, even in your own network, never mind someone else's,
either nearly, or totally, impossible, using the normal methods. The
TCP/IP solution was specifically developed to a) do the same thing if
you can't/don't want to, disable the blocks on those functions, b) get
around issues, such as alternate routing, where you are still blocked
from access, but you can't work out why, etc. Control packets are not
"necessary" for normal operation of a network. Its not unknown, since
there are some things you can do with them, other than route tracing,
and pings, for them to be disabled, but.. its like closing a port, in a
sense, if you can't talk to past what ever is blocking it, short of
having, say, some way to proxy it, you can't use it at all, any more
than you can talk to the port that has been closed.
So, yeah, its definitely the ISP's fault, in a sense, but.. again, this
is just two commands that I am talking about. There are entirely test
tools that rely on the ability to do semi-abnormal things, to get
various kinds of information, not just from the internet in general, but
just from your own network, and literally the **entire** toolset is
broken, beyond use, because the sloppy "protection" in Windows can't
tell legit testing suites from actually invalid traffic, and just
handles them all, arbitrarily as though they are threats.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 02 Sep 2013 16:50:11 -0700, Patrick Elliott wrote:
>> Sounds like ISP interference to me rather than the OS, though.
>>
> But, its not. There are a fair number of servers that, for security
> reasons, may disable the control packets, including routers in the
> primary backbones of the internet (or alternate paths). This means that
> tracing a problem, even in your own network, never mind someone else's,
> either nearly, or totally, impossible, using the normal methods. The
> TCP/IP solution was specifically developed to a) do the same thing if
> you can't/don't want to, disable the blocks on those functions, b) get
> around issues, such as alternate routing, where you are still blocked
> from access, but you can't work out why, etc. Control packets are not
> "necessary" for normal operation of a network. Its not unknown, since
> there are some things you can do with them, other than route tracing,
> and pings, for them to be disabled, but.. its like closing a port, in a
> sense, if you can't talk to past what ever is blocking it, short of
> having, say, some way to proxy it, you can't use it at all, any more
> than you can talk to the port that has been closed.
>
> So, yeah, its definitely the ISP's fault, in a sense, but.. again, this
> is just two commands that I am talking about. There are entirely test
> tools that rely on the ability to do semi-abnormal things, to get
> various kinds of information, not just from the internet in general, but
> just from your own network, and literally the **entire** toolset is
> broken, beyond use, because the sloppy "protection" in Windows can't
> tell legit testing suites from actually invalid traffic, and just
> handles them all, arbitrarily as though they are threats.
It doesn't really seem reasonable to me to hold the OS producer
responsible for not being able to do - as you call it - "semi-abnormal
things".
If the filter is behavioural, then of course it can't tell the difference
between a diagnostic tool and actual malicious traffic. Tell me, how
would *you* code the software to tell the difference between
"legitimately" wonky behaviour, and actually malicious behaviour?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 8/27/2013 3:57 PM, clipka wrote:
>> Am 27.08.2013 23:19, schrieb Patrick Elliott:
>>> On 8/27/2013 3:31 AM, Stephen wrote:
>>>> "Fractracer" <lg.### [at] gmail com> wrote:
>>>>
>>>>>
>>>>> I remember win95, a good user interface with DOS - where is DOS now?
>>>>
>>>> Hidden in the command prompt box: cmd.exe
>>>>
>>>>
>>>>
>>>>
>>> Uh. No. That is a shell, yes, and it "sort of" works like DOS, but.. its
>>> oddly missing like.. every single added program that ever came with, it,
>>> including "basic" ones, like ways to make your "shell" wait for a
>>> keypress, or any other damn thing at all. And, of course, since they
>>> *don't* want you to actually use it, they never added in any of the
>>> features that might have gotten into it (if they had stolen them from
>>> say 4DOS, or others), before Win3.11 came around.
>>
>> Well, they /did/ add support for blanks in command parameters at least.
>> And for long filenames, thank God and all the angels! (Cursed be every
>> piece of software that still makes any use of 8.3 filenames! - They're
>> /still/ in Windows for backward compatibility.)
>>
>> As for them not wanting you to use it, what they do want you to use
>> nowadays is the PowerShell. Not that I've ever heard of anyone using it
>> to solve any scripting tasks though: They either seem to be using .bat
>> files for cmd.exe, or asking you to install python.
>>
> Except that it can't bloody make up its mind when it works, and doesn't,
> some times. You get the same problem though trying to manually edit
> links. If you don't put "" around certain things the OS, despite
> supposedly knowing about bloody spaces in file names, freaks out and
> won't save it. Because, you know, the GUI should get just as confused by
> such names as the cmd.exe program does... lol
For what it's worth, most *nix shells and comand line utilities also
have a conniption when it comes to spaces in file names.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2013-08-31 22:00, Patrick Elliott a écrit :
> On 8/31/2013 10:50 AM, Jim Henderson wrote:
>> On Tue, 27 Aug 2013 18:19:45 +0100, Orchid Win7 v1 wrote:
>>
>>> What I *do* have an issue with is MS deciding that *I* can't get stuff
>>> done with my own PC because "most" end-users don't need that feature.
>>
>> Such as?
>>
>> Jim
>>
> Hmm. How about - "Without hunting down some third party tool to do it."?
> Though, some things the OS just won't let you do at all. Like, well,
> nearly any tool used to test network issues is "throttled", as in, in
> this case, "strangled" by the "protections" added, to prevent certain
> types of packets, which "might" be from a virus/worm/botnet.
You can't open sockets for ports below 1024 on *nix without being root
either.
It _IS_ to prevent bots from running under your user credentials
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2013-08-31 13:50, Jim Henderson a écrit :
> On Tue, 27 Aug 2013 18:19:45 +0100, Orchid Win7 v1 wrote:
>
>> What I *do* have an issue with is MS deciding that *I* can't get stuff
>> done with my own PC because "most" end-users don't need that feature.
>
> Such as?
>
> Jim
>
Format a >16GB USB drive with FAT32.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
