K
Klaus Kragelund
Guest
No I did not. I linked to this one:
https://www.festool.com/Microsite/Pages/TSC.aspx
https://www.festool.com/Microsite/Pages/TSC.aspx
Guest
On Fri, 11 Apr 2014 22:19:00 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
Nope. HP is torque (given the same tool). You couldn't hold onto a
saw delivering 2HP to the blade.
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
Nope. HP is torque (given the same tool). You couldn't hold onto a
saw delivering 2HP to the blade.
Guest
On Sat, 12 Apr 2014 00:32:50 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:
<klauskvik@hotmail.com> wrote:
K
Klaus Bahner
Guest
On 12-04-2014 16:48, John Larkin wrote:
[snip]
But the heartbeat problem has nothing to do with bufferoverflows etc.
The programmer did just not check (for whatever reason - there are a lot
of rumors spreading how this could happen) whether the information
coming in makes sense.
This has nothing to do with C or any other programming language. Rather
with bad design. Worse it seems to be a blow to the open source
community, which always claimed their code is better/safer than
commercially developed software, because everyone can and will check the
code. This did obviously not happen.
Actually the opposite is true. In order to become a capable C programmer
you learn that it is your responsible to make sure that your code
behaves well, when fed with garbage. Other languages tend to foster
programmers less aware of what could happen and how an attacker might
exploit weaknesses.
Actually I would claim that the majority of security problems is caused
by those interpreters. Do I have to mention Java(-script)?
times" - the Ariane 5 disaster.
Klaus
[snip]
But the heartbeat problem has nothing to do with bufferoverflows etc.
The programmer did just not check (for whatever reason - there are a lot
of rumors spreading how this could happen) whether the information
coming in makes sense.
This has nothing to do with C or any other programming language. Rather
with bad design. Worse it seems to be a blow to the open source
community, which always claimed their code is better/safer than
commercially developed software, because everyone can and will check the
code. This did obviously not happen.
Actually the opposite is true. In order to become a capable C programmer
you learn that it is your responsible to make sure that your code
behaves well, when fed with garbage. Other languages tend to foster
programmers less aware of what could happen and how an attacker might
exploit weaknesses.
Actually I would claim that the majority of security problems is caused
by those interpreters. Do I have to mention Java(-script)?
ADA has been responsible for the "most costly software failure of all
times" - the Ariane 5 disaster.
Klaus
J
John Larkin
Guest
On Sat, 12 Apr 2014 08:15:03 -0700 (PDT), edward.ming.lee@gmail.com wrote:
Reliable, secure code? Impractical!
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Reliable, secure code? Impractical!
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Guest
On Sat, 12 Apr 2014 00:28:38 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:
<klauskvik@hotmail.com> wrote:
Guest
On Sat, 12 Apr 2014 08:53:57 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:
So you admit that you're lying, now.
>ok, I'm dense, please explain in what direction that force will be?
Ever hear of "kick-back"?
<langwadt@fonz.dk> wrote:
So you admit that you're lying, now.
>ok, I'm dense, please explain in what direction that force will be?
Ever hear of "kick-back"?
J
John Larkin
Guest
On Sat, 12 Apr 2014 17:36:12 +0200, Klaus Bahner <Klaus.Bahner@ieee.org> wrote:
It was an unchecked buffer bug. Just past the assumed but unchecked buffer was
whatever else happened to be in memory. That sort of blunder has been chronic
for decades, should be impossible, and keeps happening.
There was, in the DOS days, a joke circulating that a certain JPEG file
contained a virus. A few years later, in Windows, Microsoft actually made that
possible. Same problem, trusting that a declared size was the actual size of a
structure, and data and code and stack mixed in the same memory spaces.
A strongly typed language without pointers, and with runtime bounds checking,
and compilers that use proper protections, would prevent sloppy errors like this
one.
You're joking, right? The trickier the language, the better the programmers?
ADA wasn't responsible. If someone converts a float to a 16-bit integer, to do
something like load a DAC maybe, he is obligated to consider the consequences.
That's true in any language.
At least nobody died.
http://www.ieee.li/pdf/viewgraphs/trustworthy_software.pdf
http://en.wikipedia.org/wiki/Therac-25
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
It was an unchecked buffer bug. Just past the assumed but unchecked buffer was
whatever else happened to be in memory. That sort of blunder has been chronic
for decades, should be impossible, and keeps happening.
There was, in the DOS days, a joke circulating that a certain JPEG file
contained a virus. A few years later, in Windows, Microsoft actually made that
possible. Same problem, trusting that a declared size was the actual size of a
structure, and data and code and stack mixed in the same memory spaces.
A strongly typed language without pointers, and with runtime bounds checking,
and compilers that use proper protections, would prevent sloppy errors like this
one.
You're joking, right? The trickier the language, the better the programmers?
ADA wasn't responsible. If someone converts a float to a 16-bit integer, to do
something like load a DAC maybe, he is obligated to consider the consequences.
That's true in any language.
At least nobody died.
http://www.ieee.li/pdf/viewgraphs/trustworthy_software.pdf
http://en.wikipedia.org/wiki/Therac-25
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
J
John Larkin
Guest
On Sat, 12 Apr 2014 11:32:44 -0400, krw@attt.bizz wrote:
****** Power is NOT torque! ********
You couldn't hold onto a
>saw delivering 2HP to the blade.
If the motor shaft were welded to some big object, it would be hard to hold the
saw. But the reaction torque is mostly applied to the wood being cut.
1/8 HP is silly.
http://en.wikipedia.org/wiki/File:Timber_Framing_Circular_Saw.jpg
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
****** Power is NOT torque! ********
You couldn't hold onto a
>saw delivering 2HP to the blade.
If the motor shaft were welded to some big object, it would be hard to hold the
saw. But the reaction torque is mostly applied to the wood being cut.
1/8 HP is silly.
http://en.wikipedia.org/wiki/File:Timber_Framing_Circular_Saw.jpg
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
T
tridac
Guest
On 04/12/14 14:36, edward.ming.lee@gmail.com wrote:
Actually, it was, with all the interested parties warned before it
was made public, to allow servers top be patched.
It's really not as bad as the hype anyway.
In fact, this bug is simply the result of a malloc()
requested chunk of memory only being partially filled by
the requesting application before being sent back to
the remote requesting node, the remainder of the buffer
containing what malloc() returned.
This site had an update:
https://www.schneier.com/
where Cloudflare tried to access sensitive info using this
method and got garbage.
It's not surprising. Assuming the server has 32Gbytes memory,
the buffer size 64k, then you have a possible 512,000 x 64k
blocks to examine. Also, to find out where the sensitive data
is, you first have to discover the code / process that was
using it to find the location, which means disassembling the
code, always assuming that you can find it. Also, in a virtual
memory environment, both code and data could be fragmented all
over physical address space, or the memory could have been
reallocated or overwritten. All in all, not a trivial task,
even for the security services with all the resources at their
disposal.
Summary: Storm in a teacup
...
Actually, it was, with all the interested parties warned before it
was made public, to allow servers top be patched.
It's really not as bad as the hype anyway.
In fact, this bug is simply the result of a malloc()
requested chunk of memory only being partially filled by
the requesting application before being sent back to
the remote requesting node, the remainder of the buffer
containing what malloc() returned.
This site had an update:
https://www.schneier.com/
where Cloudflare tried to access sensitive info using this
method and got garbage.
It's not surprising. Assuming the server has 32Gbytes memory,
the buffer size 64k, then you have a possible 512,000 x 64k
blocks to examine. Also, to find out where the sensitive data
is, you first have to discover the code / process that was
using it to find the location, which means disassembling the
code, always assuming that you can find it. Also, in a virtual
memory environment, both code and data could be fragmented all
over physical address space, or the memory could have been
reallocated or overwritten. All in all, not a trivial task,
even for the security services with all the resources at their
disposal.
Summary: Storm in a teacup
...
J
John Larkin
Guest
On Sat, 12 Apr 2014 09:34:12 -0700 (PDT), edward.ming.lee@gmail.com wrote:
The PDP-11 separated code, stack, and data spaces. A stack overflow made a
hardware trap, it didn't clobber code space. Code space was execute-only and
could not be written by the application running it. Data pages could be r/w or
read-only. All that in the 1970's.
C, or at least most c compilers, tangle code, data, and stacks so much that MMU
protection is not feasible. A pointer can clobber anything... bytes, longs,
floats, other pointers, stuff on stacks, opcodes.
Buffer and stack overflows, and unchecked buffers, have been chronic security
problems for decades. The language should prevent it; the culture should
routinely check it. It's disgraceful.
We have a checklist for PCB layouts. Why don't programmers have a checklist for
code?
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
The PDP-11 separated code, stack, and data spaces. A stack overflow made a
hardware trap, it didn't clobber code space. Code space was execute-only and
could not be written by the application running it. Data pages could be r/w or
read-only. All that in the 1970's.
C, or at least most c compilers, tangle code, data, and stacks so much that MMU
protection is not feasible. A pointer can clobber anything... bytes, longs,
floats, other pointers, stuff on stacks, opcodes.
Buffer and stack overflows, and unchecked buffers, have been chronic security
problems for decades. The language should prevent it; the culture should
routinely check it. It's disgraceful.
We have a checklist for PCB layouts. Why don't programmers have a checklist for
code?
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
J
John Larkin
Guest
On Sat, 12 Apr 2014 10:23:32 -0700 (PDT), haiticare2011@gmail.com wrote:
Working in c, always check every buffer for size errors. Study every pointer.
Don't just write the code, READ it. Comment heavily, because commenting is a
code review of sorts all by itself. c is of course a mostly write-only language
and the culture discourages comments.
Or program in a better language, that simply doesn't allow data, or programming
errors, to create system-level hazards.
The CS departments of the world should have Manhattan-project, Man-on-the-moon
scale projects to make computing reliable. They have other priorities.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Working in c, always check every buffer for size errors. Study every pointer.
Don't just write the code, READ it. Comment heavily, because commenting is a
code review of sorts all by itself. c is of course a mostly write-only language
and the culture discourages comments.
Or program in a better language, that simply doesn't allow data, or programming
errors, to create system-level hazards.
The CS departments of the world should have Manhattan-project, Man-on-the-moon
scale projects to make computing reliable. They have other priorities.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
S
Spehro Pefhany
Guest
On Sat, 12 Apr 2014 04:29:44 -0700 (PDT), the renowned Lasse Langwadt
Christensen <langwadt@fonz.dk> wrote:
Yes, that's what I'm talking about.
And a moment's inattention or misjudgment can result in permanent
injury. Metalworking tends to be safer, IMHO.. you never get near the
sharp bits during operation.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Christensen <langwadt@fonz.dk> wrote:
Yes, that's what I'm talking about.
And a moment's inattention or misjudgment can result in permanent
injury. Metalworking tends to be safer, IMHO.. you never get near the
sharp bits during operation.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Guest
On Saturday, April 12, 2014 3:27:03 PM UTC-7, k...@attt.bizz wrote:
And I go on facebook to play poker only. Don't post any real data. Can't believe people are posting so much personal data for scamer to harvest. I have no friend on facebook. I am anti-social.
And I go on facebook to play poker only. Don't post any real data. Can't believe people are posting so much personal data for scamer to harvest. I have no friend on facebook. I am anti-social.
T
Tim Williams
Guest
"tridac" <design42@ceeq.org> wrote in message
news:libr1n$b85$1@dont-email.me...
Very easily resolved using DNA analysis techniques.
What? Yes; typically, when DNA is analyzed, they chop it up into
manageable pieces (~500 base pairs) and, back in the day, you'd do a gel
electrophoresis (mass spectrum resulting in those ghostly bars prints they
used to exhibit on TV), but I forget what's done nowadays (obviously,
something with more precision and throughput!). A pattern matching
algorithm finally hunts for overlapping segments and reassembles a likely
result.
Note that large swaths of repeated information screw up the process, which
does happen from time to time (chromosomal transposons and stuff).
The human genome is in the TB size range, so the practicality of doing
such an attack -- exhaustively, not just to find tasty clues -- isn't
impossible. Though it would be at the very least difficult to reconstruct
a coherent image of memory that's constantly changing. But 'tis the same
way: people had some idea what DNA is, and what parts of it do (genes),
decades before full-on sequencing was developed. All it takes in this
case is a few errant keys and you've got big problems.
Tim
--
Seven Transistor Labs
Electrical Engineering Consultation
Website: http://seventransistorlabs.com
news:libr1n$b85$1@dont-email.me...
It's not surprising. Assuming the server has 32Gbytes memory,
the buffer size 64k, then you have a possible 512,000 x 64k
blocks to examine. Also, to find out where the sensitive data
is, you first have to discover the code / process that was
using it to find the location, which means disassembling the
code, always assuming that you can find it. Also, in a virtual
memory environment, both code and data could be fragmented all
over physical address space, or the memory could have been
reallocated or overwritten. All in all, not a trivial task,
even for the security services with all the resources at their
disposal.
Summary: Storm in a teacup
Very easily resolved using DNA analysis techniques.
What? Yes; typically, when DNA is analyzed, they chop it up into
manageable pieces (~500 base pairs) and, back in the day, you'd do a gel
electrophoresis (mass spectrum resulting in those ghostly bars prints they
used to exhibit on TV), but I forget what's done nowadays (obviously,
something with more precision and throughput!). A pattern matching
algorithm finally hunts for overlapping segments and reassembles a likely
result.
Note that large swaths of repeated information screw up the process, which
does happen from time to time (chromosomal transposons and stuff).
The human genome is in the TB size range, so the practicality of doing
such an attack -- exhaustively, not just to find tasty clues -- isn't
impossible. Though it would be at the very least difficult to reconstruct
a coherent image of memory that's constantly changing. But 'tis the same
way: people had some idea what DNA is, and what parts of it do (genes),
decades before full-on sequencing was developed. All it takes in this
case is a few errant keys and you've got big problems.
Tim
--
Seven Transistor Labs
Electrical Engineering Consultation
Website: http://seventransistorlabs.com
R
Robert Baer
Guest
Skybuck Flying wrote:
GM, This SHIT company once had criticism on Microsoft's Windows START
button. Claiming that it would be illogical to use the "start" key to
shut down the system.
To me as a programmer it makes complete sense to "start" the shutdown
procedure. So their criticism from an enginering point of view is BOGUS.
Now what comes around goes around you ll see.
Now they face their own stupid engineering crisis:
Their own START KEY IS FLAWED ! and apperently they tried to hide it !:
http://www.thecarconnection.com/news/1091399_gm-suspends-engineers-adds-recall-repair-ups-cost-to-1-3m
SHAME ON THIS COMPANY CALLED GENERAL MOTORS.
May they rott in hell.
Bye,
Skybuck.
P.S.: Don't buy CARS from General Motors if you want to live !
The name now is Government Motors...
Guest
On Sat, 12 Apr 2014 09:42:20 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
so...
Without reaction from the wood, there is little reason for power.
>1/8 HP is silly.
Wrong.
>http://en.wikipedia.org/wiki/File:Timber_Framing_Circular_Saw.jpg
At least you've admitted that you've lost the argument.
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
******Power is torque X RPM! ******** Like tools have similar RPM,
so...
Without reaction from the wood, there is little reason for power.
>1/8 HP is silly.
Wrong.
>http://en.wikipedia.org/wiki/File:Timber_Framing_Circular_Saw.jpg
At least you've admitted that you've lost the argument.
Guest
On Sat, 12 Apr 2014 12:23:44 -0700 (PDT), Klaus Kragelund
<klauskvik@hotmail.com> wrote:
Yes, you did.
<klauskvik@hotmail.com> wrote:
Yes, you did.
Guest
On Sat, 12 Apr 2014 10:41:22 -0700 (PDT), edward.ming.lee@gmail.com
wrote:
I think the social media market is crashing because the subscription
lies are coming out (44% of twitter accounts have never tweeted). No
problem. The IPO is over and the suckers now own the pig, lipstick
and all.
wrote:
I think the social media market is crashing because the subscription
lies are coming out (44% of twitter accounts have never tweeted). No
problem. The IPO is over and the suckers now own the pig, lipstick
and all.
M
Maynard A. Philbrook Jr.
Guest
In article <c20hk9tnsm05vbirg1uuauaj6jv2q6f011@4ax.com>,
jlarkin@highlandtechnology.com says...
A universal motor is a work horse in a small package.
At 13 amps you are getting 2 HP.
However, they like to eat up brushes, not very good for a constant
speed application and is important to keep a load on them..
We have 2 HP vacuum loader systems at work and those that have the
universal motors, you can hold the motor in your hand.
Jamie
jlarkin@highlandtechnology.com says...
A universal motor is a work horse in a small package.
At 13 amps you are getting 2 HP.
However, they like to eat up brushes, not very good for a constant
speed application and is important to keep a load on them..
We have 2 HP vacuum loader systems at work and those that have the
universal motors, you can hold the motor in your hand.
Jamie