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