On 28/08/2020 13:38, Martin Gregorie wrote:
I'm really disapointed that there hasn't been more work done on both
hardware as OS design to make cross-process interference impossible and
to properly implement hardware protection rings to stop application-level
code clobbering the OS and the OS from clobbering to low-level drivers.
Problem is look-ahead caching
Modern processors use it to gain speed, but it blows away process compartmentalisation.
You really thought that back then? It's what allowed
them to beat Netscape. For years it was a brilliant
design. It still is. It's just not safe. I write a lot of
HTAs, using script and COM for the functionality and
IE for the GUI.
The Natural Philosopher wrote:
Martin Gregorie wrote:
I'm really disapointed that there hasn't been more work done on both
hardware as OS design to make cross-process interference impossible
and to properly implement hardware protection rings to stop
application-level code clobbering the OS and the OS from clobbering
to low-level drivers.
Problem is look-ahead caching
Modern processors use it to gain speed, but it blows away process
compartmentalisation.
It doesn't blow it away; it makes a very very difficult and very very ineffective attack theoretically possible.
I'm pretty certain none of these timing related speculative execution vulnerabilities have ever been found being used "in the wild" by
malicious hackers.
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote
| > That kind of thing. I though MS were brilliant with
| > ActiveX. They just didn't see the security problems
| > coming.
|
| Whereas some of us saw ActiveX for the first time and shook our
| heads in sorrow because it looked like the most stupid idea we'd seen
since
| email clients that allowed attachments to execute.
|
You really thought that back then?
It's what allowed
them to beat Netscape. For years it was a brilliant
design. It still is. It's just not safe.
Similarly with email. It was perfectly safe for quite awhile before
people started getting the idea to start sending attack files named something.doc.exe.
Throughout this era that was little attention given to security
I started programming in 1978 and have a slightly different take on it.
On Sat, 29 Aug 2020 20:30:21 -0400
"Mayayana" <mayayana@invalid.nospam> wrote:
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote
That kind of thing. I though MS were brilliant with
ActiveX. They just didn't see the security problems
coming.
Whereas some of us saw ActiveX for the first time and shook our
heads in sorrow because it looked like the most stupid idea we'd seen
since email clients that allowed attachments to execute.
You really thought that back then?
On sight, wrt to the executable email attachments it wasn't long
before it happened that I was telling people that nobody would be stupid enough to do it.
It's what allowed them to beat Netscape. For years it was a brilliant
design. It still is. It's just not safe.
It's a stupid design because it cannot be safe.
Even one super solar flare, which supposedly happens
every few hundred years could possibly fry all integrated
circuits. 30 years ago that would have been a minor
issue. Today it would stop cars, computers, utilities...
everything. Yet people keep spending hundreds of dollars
for watches to tell them their heart is beating. So I
try to avoid unnecessary computerization.
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote
| > It's what allowed
| > them to beat Netscape. For years it was a brilliant
| > design. It still is. It's just not safe.
|
| It's a stupid design because it cannot be safe.
Yes. They eventually had to accept that. And they
eventually had to swallow their pride and move toward
web standards. But what's happening now is also not
safe. Javascript is being used in the MBs per page.
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote
| > | It's a stupid design because it cannot be safe.
| >
| > Yes. They eventually had to accept that. And they
| > eventually had to swallow their pride and move toward
| > web standards. But what's happening now is also not
| > safe. Javascript is being used in the MBs per page.
|
| Yep it's what happens when everyone else is forced to play catchup
| with someone taking insane risks.
You think MS is to blame? Javascript was being phased
out, with close to 10% of people disabling it, a few years
sgo. The same with iframes. What changed it had nothing
to do with Microsoft. It was targetted ads and the spying
that goes with them.
I'm still amazed at who is the President of the United States
You think MS is to blame? Javascript was being phased
out, with close to 10% of people disabling it, a few years
sgo. The same with iframes. What changed it had nothing
to do with Microsoft. It was targetted ads and the spying
that goes with them.
On Sat, 29 Aug 2020 19:49:09 +0000, Martin Gregorie wrote:
I started programming in 1978 and have a slightly different take on it.Unspotted mistake - for 1978 read 1968 - that was when I joined ICL and learned PLAN assembler.
On 30/08/2020 16:40, Martin Gregorie wrote:I first coded in FORTRAN. all there was then was ALGOL, FORTRAN and COBOL.
On Sat, 29 Aug 2020 19:49:09 +0000, Martin Gregorie wrote:
I started programming in 1978 and have a slightly different take on it.Unspotted mistake - for 1978 read 1968 - that was when I joined ICL and
learned PLAN assembler.
I was going to pull you up on that as Cobol was well established by 78,
but figured from the rest of the post that wasn't right.
In any case I was born in 1968, and started programming on the BBC Micro
in the early 80s, so luckily I avoided Cobol then and ever since.
---druck
"The Natural Philosopher" <tnp@invalid.invalid> wrote
| It is to be understood that the moment an initiative for freedom or
| genuine popular expression occurs, within a decade it will be bought,
| controlled infiltrated and destroyed by big business and the profit
| motive, and political activists.
|
| Allowing the people to have free access to global communication was
| intolerable. How would the lies of cultural propaganda and product
| marketing be believed if everybody talked to each other and decided that
| their product was, in fact, shit?
|
There's always someone to cash in. But there are also
millions of ostriches who just want to buy cheap stuff
and would prefer that Google know what they're looking
for. The travesty of the Web as spyware shopping mall
was creatable due to demand.
In any case I was born in 1968, and started programming on the BBC Micro
in the early 80s, so luckily I avoided Cobol then and ever since.
Early COBOLs would allow you to call assembler subroutines but the
language did not allow external subroutines to be written in COBOL. I
don't remember seeing this feature in any implementation before 1978.
Early COBOLs also required a program to be a single source file though it
had a COPY statement that could be used to pull in record definitions or >sections of code. Fortunately, the compilers could handle huge source
files: a program of less then 200 lines usually did nothing useful.
Programs were generally in the 1000-4000 line range though I have seen a
few in the 10,000 line range.
There was a built-in Y2K gotcha too: The only way you could get hold of
the date was with a statement like
ACCEPT DATE-TODAY FROM SYSTEM-DATE.
where the DATE-TODAY variable *had* to be declared in working storage as:
01 DATE-TODAY PIC 9(6).
and the ACCEPT statement would fill it with a date formatted as 'yymmdd'. >This requirement was defined in the CODASYL Report (i.e. was part of the >language standard) and AFAIK it was not changed until after Y2K had been
and gone.
I first coded in FORTRAN. all there was then was ALGOL, FORTRAN and
COBOL.
Then came B, BCPL and C...and then after that trash languages designed
to let monkeys think they could code
On Mon, 31 Aug 2020 17:01:31 +0100, druck wrote:
In any case I was born in 1968, and started programming on the BBC MicroCOBOL wasn't actively evil (apart from the ALTER statement - and that had vanished by the mid-80s. It just far too verbose:
in the early 80s, so luckily I avoided Cobol then and ever since.
ADD A to B GIVING C ON SIZE ERROR PERFORM OVERFLOW-TRAP.
where the Java equivalent would be something like:
try {
c = a + b;
}
catch (ArithmeticException e) {
overflowTrap(e);
}
There's also a lot of typing involved because of the size ot variable
names and the number of them you have to define:
- fields in structures have names that aren't linked in any way to the
structure's name.
- if a program reads a value from an input file, writes it to a database
file and prints it in a report or displays it on screen, you'll end
defining the variable three times and the input and display forms will
be slightly different because they define external format.
That said, COBOL did at least always let you catch ON SIZE ERROR overflow exceptions, which is more than could be said for other contemporary HLLS
such FORTRAN. Specifying formats for input and output fields was also
always pretty straight-forward and intuitive.
However it had some terrible features such as the ALTER verb, which
allowed a running COBOL program to self modify, making debugging hellish.
Early COBOLs would allow you to call assembler subroutines but the
language did not allow external subroutines to be written in COBOL. I
don't remember seeing this feature in any implementation before 1978.
Early COBOLs also required a program to be a single source file though it
had a COPY statement that could be used to pull in record definitions or sections of code. Fortunately, the compilers could handle huge source
files: a program of less then 200 lines usually did nothing useful.
Programs were generally in the 1000-4000 line range though I have seen a
few in the 10,000 line range.
There was a built-in Y2K gotcha too: The only way you could get hold of
the date was with a statement like
ACCEPT DATE-TODAY FROM SYSTEM-DATE.
where the DATE-TODAY variable *had* to be declared in working storage as:
01 DATE-TODAY PIC 9(6).
and the ACCEPT statement would fill it with a date formatted as 'yymmdd'. This requirement was defined in the CODASYL Report (i.e. was part of the language standard) and AFAIK it was not changed until after Y2K had been
and gone.
I don't think it was. When I was MD marketing no marketing director was
ever able to actually determine how much of their massive budget
actually produced sales. Instead they simply treated it as a religion.
One had to have faith in it actually working.
I'm pretty certain the COBOL-74 standard provided for external modules
to be linked -- my Xerox Sigma-6 manual is in storage so I can't confirm
Strangely, while I'm sure my course introduced linking separately compiled COBOL modules, we were NOT introduced to "COPY" statements.
Though that is a minor problem -- since it returns the current
date, it at least was easy to detect century wrap-around and preface
with the correct 19 or 20.
Not so simple is the case of data records that could span a range
where "windowing" was not feasible.
Java was being phased out.
If you get attacked online it will almost certainly be
because you enabled script and/or enabled remote access
functions so you could call your thermostat to tell it
you're on your way home.
gareth evans <headstone255@yahoo.com> writes:
Is it true that the RPi4 is susceptible to these
security attacks but that no previous versions are?
https://developer.arm.com/support/arm-security-updates/speculative- processor-vulnerability
describes which cores are susceptible to which attacks. The variants
that the Pi4’s CPU are vulnerable to are as follows:
* Variants 1 and 2 (CVE-2017-5753 and CVE-2017-5715) are Spectre. An
attacker can bypass validity checks and access data that’s supposed
to be secret.
* Variant 3A (CVE-2018-3640) is essentially Meltdown but for registers
instead of memory. An attacker can bypass CPU-level privilege checks
and read access data that is supposed to be secret.
* Variant 4 (CVE-2018-3639) is a speculative store bypass. An attacker
can access data that was supposed to have been overwritten.
The other Pi CPU cores are not listed and therefore not vulnerable to
any known speculation-based attacks.
Since the original Spectre/Meltdown research, a _lot_ of variants have
been identified. It’s likely that there are more to come. Arm’s
record has been very good here, but it’s not impossible that future
issues may impact Arm cores too.
I started programming in 1978 and have a slightly different take on it.
Unspotted mistake - for 1978 read 1968 - that was when I joined ICL and
learned PLAN assembler.
I was going to pull you up on that as Cobol was well established by 78,
but figured from the rest of the post that wasn't right.
In any case I was born in 1968, and started programming on the BBC Micro
in the early 80s, so luckily I avoided Cobol then and ever since.
Hello Richard,
https://developer.arm.com/support/arm-security-updates/speculative-
processor-vulnerability
describes which cores are susceptible to which attacks. The variants
that the Pi4âs CPU are vulnerable to are as follows:
* Variants 1 and 2 (CVE-2017-5753 and CVE-2017-5715) are Spectre. An
attacker can bypass validity checks and access data thatâs supposed >> to be secret.
* Variant 3A (CVE-2018-3640) is essentially Meltdown but for registers
instead of memory. An attacker can bypass CPU-level privilege checks
and read access data that is supposed to be secret.
* Variant 4 (CVE-2018-3639) is a speculative store bypass. An attacker
can access data that was supposed to have been overwritten.
The other Pi CPU cores are not listed and therefore not vulnerable to
any known speculation-based attacks.
Since the original Spectre/Meltdown research, a _lot_ of variants have
been identified. Itâs likely that there are more to come. Armâs
record has been very good here, but itâs not impossible that future
issues may impact Arm cores too.
Can you explain us how we can find out which versions can attack which Pi versions?
COBOL wasn't actively evil (apart from the ALTER statement - and that had vanished by the mid-80s. It just far too verbose:
ADD A to B GIVING C ON SIZE ERROR PERFORM OVERFLOW-TRAP.
where the Java equivalent would be something like:
try {
c = a + b;
}
catch (ArithmeticException e) {
overflowTrap(e);
}
There's also a lot of typing involved because of the size ot variable
names and the number of them you have to define:
On 2020-08-31, Mayayana <mayayana@invalid.nospam> wrote:
Java was being phased out.
That's because M$ tried to add proprietary extensions
to it - in violation of their licensing agreement with
Sun - and they got caught at it.
Depends in the application: what you suggest works fine for the date on a >report or at the top of a screen, but becomes a problem in other cases -
I remember seeing a payroll back in the late '60s (6 digit date days)
that *HAD* to handle birth dates in the 1890s. Not altogether easy on a >system whose base date was 1/1/1900 !
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote
Java was being phased out.
That's because M$ tried to add proprietary extensions
to it - in violation of their licensing agreement with
Sun - and they got caught at it.
I don't understand why so many people want to cast
Microsoft as the only villain. Yes, MS tried to come up
with their own version of Java. But that's not why Java
was phased out.
Long story short, I don't see how you can blame Java's
failure on MS.
Remember those science fiction stories where you could do
stuff like that? Back then it worked because it was assumed
that smart houses would be independent entities (with suitable
access controls), rather than slaves of the Cloud.
It's my impression that people are doing it. People
get calls from their surveillance cameras to say someone
has broken into their house, for instance.
Soon, the more feebleminded will probably be calling their frig
to see if they need milk. And they'll be bragging about it.
There was an interesting story some years ago about
2 men who were rich, flying a private plane to a hunting
cabin one of them owned. The owner used his iPhone
to call his thermostat, so the cabin would be warm when
they arrived. It turned out that a squirrel had built a nest
in the furnace exhaust pipe and there were no working
CO alarms. When the two men arrived they were dead
before they had time to notice something was wrong.
I've also seen stories about hacked e-front door locks.
People are eating up the IoT, no matter how dumb. I
suppose it is all cloud-linked, but isn't that really
a privacy issue rather than a functionality issue?
I don't understand why so many people want to cast
Microsoft as the only villain. Yes, MS tried to come up with their own version of Java.
But that's not why Java was phased out. It was phased
out because it was bloated and unsafe and didn't belong in webpages.
And you know I still am a very active member of the Dutch Big Ben Club for Acorn and RISC OS computers for 36 years.
Pity we have to calm down our meetings because of CoVid19 ;-(.
Greetings from Henri, to your wife too.
She knows me from the Britisch computer shows I visited several times.
On Tue, 01 Sep 2020 09:19:26 -0400, Mayayana wrote:
I don't understand why so many people want to cast
Microsoft as the only villain. Yes, MS tried to come up with their own
version of Java.
In this case that's because they were: you do NOT grab somebody else's product (at that time it belonged to Sun and no part of it was open
source), hack it about to suit yourself without consulting anybody, least
of all the originators and standardisation people, and then try to flog
it to all and sundry. Thats very little different to the way M$ bought
what became MSDOS from its originators so they had something to flog to
IBM, though they did at least buy MSDOS it from its authors. I forget
what, if anything they paid Sun for Java.
Yes. Except that it didn't really work. And it never belonged
in webpages. And it never belonged on the desktop. As I said,
it's used for in-house applets, just as .Net is. Neither of them is well suited to desktop. What is? Compiled software.
I forget what Javascript was originally called,
What I've been seeing as hack attempts to make cross-platform
software seems to be mostly Python. And some other packaged kits for
specific functionality. That's not really cross-platform. Cross-platform
is software written in versions that run to the various platforms,
targetting the platform API.
Great, but not for desktops.
On Tue, 01 Sep 2020 21:07:14 -0400, Mayayana wrote:
Yes. Except that it didn't really work. And it never belonged
in webpages. And it never belonged on the desktop. As I said,
it's used for in-house applets, just as .Net is. Neither of them is well suited to desktop. What is? Compiled software.
What are you talking about?
Javascript != Java and has never been even remotely connected with Java except that Netscape tried without success to build it into their browser. Meanwhile they had a parallel project for an interpreted language called Scheme which added a few syntactical and functional elements copied from
Java and ended up being called LiveScript, then renamed to JavaScript and later standardised as ECMAScript.
So, the differences are:
- the two languages are syntactically different apart from some features
in common with other languages such as curly brackets and other syntax
that originated from C.
- Javascript is interpreted while Java is compiled
Not true. Java programs using the SWING GUI run just fine on my Linux
systems and would run equally well under Windows - no recompilation
needed.
In article <rimuf3$f0u$1@dont-email.me>, Martin Gregorie <martin@mydomain.invalid> wrote:
Not true. Java programs using the SWING GUI run just fine on my Linux systems and would run equally well under Windows - no recompilation
needed.
Unclear how you intend that to square with your claim that Java (vs. JavaScript) is compiled.
There is JavaScript which has been on browsers for a long time (and has
seen increasing use and increasing support) and there are Java applets,
which are a completely different beast.
- Javascript is interpreted while Java is compiled
Interpreted and compiled implementations are different points on a
continuum, they are not one-or-the-other propositions.
There are certainly things called JavaScript compilers running on
browsers these days (I believe the one used most widely is from Google
and was a large step forward compared to previous, interpreted implementations in terms of performance of the code produced). I don't
know to what degree it "compiles" JavaScript, I doubt it goes to native
code.
Java has been implemented in more than one way. Including in the
"compiler" from Oracle, nee Sun, which, I am told by people who have
worked on it, contains three separate Java compilers in the same javac binary. Which compiler you get is determined by which flags (among 120
or so) you choose on the command line and this internal structure is not visible to the user. None of these, to my knowledge, "compile" to native code, they compile to an intermediate language which is then
interpreted.
Unclear how you intend that to square with your claim that Java (vs. JavaScript) is compiled.
ubiquitous. Java was on the same path when Microsoft violated the
licensing agreement. Sun sued, and the judge gave Microsoft 90 days
to either comply with the agreement or pull Windows 98 off the market. Microsoft had no choice but to back down - but it's little wonder that
they suddenly lost interest in Java.
You can call Java compiled if you want to count JIT,I don't thing yo go.
but you know perfectly well what I'm talking about.
Java, like .Net, is far slower than native compiled software.
Then why is there virtually no Java software on the
Desktop? Even .Net is not common. It's more common now, since MS started pre-installing the runtimes. But like Java, it's not optimized for
desktop.
Mayayana wrote:
Java, like .Net, is far slower than native compiled software.
Might have been once, but current versions are pretty slick. Its a bit
slower when its getting started and pulling in library classes from disk,
but that its not what you'd call slow.
Martin Gregorie <martin@mydomain.invalid> writes:
Mayayana wrote:
Java, like .Net, is far slower than native compiled software.
Might have been once, but current versions are pretty slick. Its a bit
slower when its getting started and pulling in library classes from disk,
but that its not what you'd call slow.
Mono’s CIL JIT was empirically beating GCC on computationally intensive code a decade ago (probably by making better register allocation choices although I didn’t delve into it deeply). No idea what the situation is today but I’d expect them to be pretty similar.
On 28/08/2020 21:53, Pancho wrote:
On 28/08/2020 20:19, Dennis Lee Bieber wrote:
If ARM is considered RISC, it is still pipelined:ARM is pipelined, I think all chips are now.
https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2011/september/ar m-pipeline-and-gdb-oh-my/
https://en.wikipedia.org/wiki/ARM_architecture#Pipelines_and_other_implementati on_issues
Even the ARM2 was pipelined, you'll probably have to go back to the 8
bit ear such as the 6502, to find one which wasn't.
On 03/09/2020 09:47, Richard Kettlewell wrote:
Mono’s CIL JIT was empirically beating GCC on computationally intensive
code a decade ago (probably by making better register allocation choices
although I didn’t delve into it deeply). No idea what the situation is
today but I’d expect them to be pretty similar.
Yeah, maybe optimal reordering of instructions and branch prediction
too, in combination with register allocation. C# was brilliant at
numerical analysis type performance right from the get-go.
I have a vague memory of .net runtime statistics being stored and used
to optimise subsequent runs of a program, but after a quick google I'm
not sure if I just made that up.
No mention of pipelines in my copy of "Assembly Language Programming for
the BBC Microcomputer" by Ian Birnbaum.
Pancho <Pancho.Dontmaileme@outlook.com> wrote:
No mention of pipelines in my copy of "Assembly Language Programming for
the BBC Microcomputer" by Ian Birnbaum.
Nor in this seminal machinecode book of the 80's https://ee1.nl/misc/machinecode.pdf (15 MB)
Martin Gregorie <martin@mydomain.invalid> writes:
Mayayana wrote:
Java, like .Net, is far slower than native compiled software.
Might have been once, but current versions are pretty slick. Its a bit
slower when its getting started and pulling in library classes from disk,
but that its not what you'd call slow.
Mono’s CIL JIT was empirically beating GCC on computationally intensive code a decade ago (probably by making better register allocation choices although I didn’t delve into it deeply). No idea what the situation is today but I’d expect them to be pretty similar.
On 03/09/2020 18:23, A. Dumas wrote:
Pancho <Pancho.Dontmaileme@outlook.com> wrote:
No mention of pipelines in my copy of "Assembly Language Programming for >>> the BBC Microcomputer" by Ian Birnbaum.
Nor in this seminal machinecode book of the 80's
https://ee1.nl/misc/machinecode.pdf (15 MB)
Neither the 6502 or Z80 were pipelined, but if they were it wouldn't be something that needs to concern the programmer, even when using
assembler. The same is true for the ARM.
This isn't the case for all processors, as some early RISC chips such as
MIPS expose the effects of pipe-lining by having a branch delay slot
i.e. the instruction after a branch will be executed regardless of
whether the branch is taken or not, as it is already in the pipeline.
Most other processor flush any instructions in the pipeline after a
taken branch, which was could be wasteful until good branch prediction
came along, although most slots were filled with No Ops in practice. Processors also have much longer pipelines now, and it would be very difficult to code for a variable number of branch delay slots.
ARM tackled pipe-lining issues in in Aarch32 by eliminating the need for
most small branches by using conditional instructions, which was great
when programming by hand. This has been deprecated by better branch prediction and the use of Thumb, which has an IF THEN ELSE instruction
to determine which of the following 4 instructions is executed depending
on a condition.
Aarch64 has eliminated conditional codes from all instructions except
for branches, but has a small number of conditional arithmetic
instructions. For example CSEL allows you to calculate the result of
both the THEN ELSE instructions (usually in parallel with superscalar
chips) then chose which value to use.
---druck
On 4.9.20 12.10, druck wrote:
In the 32 bit ARM (ARM7TDMI and relatives), the conditionality is in the
top 4 bits of most instructions.
In the same chips, the pipelining peeks in two places:
- offsets of PC-relative addresses,
- return addresses of exceptions.
On 04/09/2020 13:36, Tauno Voipio wrote:
On 4.9.20 12.10, druck wrote:
In the 32 bit ARM (ARM7TDMI and relatives), the conditionality is in the
top 4 bits of most instructions.
Most of the NV (never) variants have been repurposed as new instructions
now, as they were never that useful.
In the same chips, the pipelining peeks in two places:
- offsets of PC-relative addresses,
- return addresses of exceptions.
Well remembered. It was a side effect of the very simple logic in ARM2
which had a 3 stage pipeline so value of the PC register was always +8*
of the currently executing instruction (ignoring Thumb which is +4).
Its a shame there wasn't the budget for a few extra transistors to 'fix'
this at the time, because this behaviour has had to be preserved on
every subsequent ARM, no matter how many stages it has.
* There is one place where it is +12, can't remember where though!
---druck
ARM tackled pipe-lining issues in in Aarch32 by eliminating the need for
most small branches by using conditional instructions, which was great
when programming by hand. This has been deprecated by better branch prediction
| Whereas some of us saw ActiveX for the first time and shook our
| heads in sorrow because it looked like the most stupid idea we'd
| seen since email clients that allowed attachments to execute.
You really thought that back then? It's what allowed
them to beat Netscape.
For years it was a brilliant design. It still is. It's just not
safe.
In article <riervj$9gq$1@dont-email.me>, Mayayana wrote:
| Whereas some of us saw ActiveX for the first time and shook our
| heads in sorrow because it looked like the most stupid idea we'd
| seen since email clients that allowed attachments to execute.
You really thought that back then? It's what allowed
them to beat Netscape.
Let me see ... I can write an executable program that I can put into a >webpage, and when a user visits the webpage my program will run
natively on their machine with all the rights and privileges of the
current user ... how could that go wrong?
It was compete insanity on Microsoft's part from the word "go", and
should never have been released. It was, however, quite typical of the
way that MS thought only about enabling technologies and never about >moderating or policing those technologies.
For years it was a brilliant design. It still is. It's just not
safe.
If it's not safe it's not brilliant. Quite the opposite.
.. and MS didn't "beat" Netscape, not really. Firefox is still with us
and it's Chrome that's growing most in market share.
Netscape was maintained by
AOL for awhile, if I remember correctly, then was released
as an OSS code base.
It was awhile before Firefox got off the ground.
At that time there was no Chrome. You
may not remember it, but around 2000 there was pretty
much just IE on Windows.
Today, IE/Edge are pretty much kaput, despite that MS
is trying hard to force Chrome/Edge. But Netscape is long,
long gone.
On 03/09/2020 09:47, Richard Kettlewell wrote:
Martin Gregorie <martin@mydomain.invalid> writes:
Mayayana wrote:
Java, like .Net, is far slower than native compiled software.
Might have been once, but current versions are pretty slick. Its a bit
slower when its getting started and pulling in library classes from
disk,
but that its not what you'd call slow.
Mono’s CIL JIT was empirically beating GCC on computationally intensive
code a decade ago (probably by making better register allocation choices
although I didn’t delve into it deeply). No idea what the situation is
today but I’d expect them to be pretty similar.
I'd say that from what I'm doing the Mono CIL on AMD64 is between 1.5x
and 8x slower. For computational intensive stuff probably about 4x. Half
that on the Windows CLR.
On the Raspberry Pi 4B mono is about 9x slower for both 32 and 64 bit
OS's, so a far less mature JIT.
On 04/09/2020 10:35, druck wrote:
I'd say that from what I'm doing the Mono CIL on AMD64 is between 1.5x
and 8x slower. For computational intensive stuff probably about 4x.
Half that on the Windows CLR.
That surprises me, my memory from circa 2003 was that C# numerical stuff
ran at about the same speed as C++, my memory is poor to exact details,
I would have probably have categorized 80% as the same speed. I would
have probably tested using some type of numerical integration routine.
I don't know how you tested, I do remember there was a performance
penalty gotcha from switching between managed and unmanaged code.
So you disable all javascript, I presume? Or do you just log
on as a lackey user who has no access to the Internet?
| If it's not safe it's not brilliant. Quite the opposite.
No, not if you understand COM. It allows for
script and other non-compiled code to call compiled
libraries, which are registered on the system. It works
very well. Before .Net, Java, Flash, etc there was COM
providing relatively easy and safe wrapper components.
But COM/ActiveX is still a brilliant, flexible design today, as
long as it's used offline.
| .. and MS didn't "beat" Netscape, not really. Firefox is still
| with us and it's Chrome that's growing most in market share.
I'm going to give you the benefit of the doubt and
assume you've been hanging around the barbecue, drinking,
for most of this Labor Day Saturday.
You may not remember it, but around 2000 there was pretty
much just IE on Windows.
ActiveX, 2 scripting options, and catering to corporate
sysadmins, as well as building IE into Windows, made
Netscape an impossible proposition.
I'd say that from what I'm doing the Mono CIL on AMD64 is
between 1.5x and 8x slower. For computational intensive stuff
probably about 4x. Half that on the Windows CLR.
That surprises me, my memory from circa 2003 was that C# numerical
stuff ran at about the same speed as C++, my memory is poor to
exact details, I would have probably have categorized 80% as the
same speed. I would have probably tested using some type of
numerical integration routine.
I do remember there was a performance penalty gotcha from
switching between managed and unmanaged code.
Mayayana wrote:
So you disable all javascript, I presume? Or do you just log
on as a lackey user who has no access to the Internet?
Javascript and ActiveX are completely different propositions.
Javascript programs are executed within an environment defined by the browser, and are sandboxed so that they do not have access to the
native OS (bugs notwithstanding).
We did have a mono project that had a huge problem with garbage
collection (either of the gc's) when mixing managed and unmanaged
code, as unmanaged data got stuck in the heap causing it to fragment
and continually grow. It ended up being slower and more prone to
falling over than the Python prototype. RK will remember that one.
"Pancho" <Pancho.Dontmaileme@outlook.com> wrote
|
| That surprises me, my memory from circa 2003 was that C# numerical stuff
| ran at about the same speed as C
Why would you only care about that, though?
What if you have a C# program that just doing
something like FTP?
On 06/09/2020 11:04, Pancho wrote:
On 04/09/2020 10:35, druck wrote:
I'd say that from what I'm doing the Mono CIL on AMD64 is between
1.5x and 8x slower. For computational intensive stuff probably about
4x. Half that on the Windows CLR.
That surprises me, my memory from circa 2003 was that C# numerical
stuff ran at about the same speed as C++, my memory is poor to exact
details, I would have probably have categorized 80% as the same speed.
I would have probably tested using some type of numerical integration
routine.
I don't know how you tested, I do remember there was a performance
penalty gotcha from switching between managed and unmanaged code.
Just managed code.
We did have a mono project that had a huge problem with garbage
collection (either of the gc's) when mixing managed and unmanaged code,
as unmanaged data got stuck in the heap causing it to fragment and continually grow. It ended up being slower and more prone to falling
over than the Python prototype. RK will remember that one.
You pick a language to suit the task. First you test to see if a
language is suitable for a type of task, which is why I was benchmarking
C#.
You pick a language to suit the task. First you test to see if a
language is suitable for a type of task, which is why I was benchmarking
C#.
I use bash scripts as well as C#.
"Richard Kettlewell" <invalid@invalid.invalid> wrote
Secondly the legitimate API surface available to JavaScript keeps on
growing. It still can't do everything, but the gap keeps shrinking.
Finally as more functionality moves to web applications, the less the
distinction matters. For example the fact that JavaScript can't access
your local files isn't very relevant if the stuff you care about is in
Google Docs.
Yes. And now there's WebAssembly. It's clear
that Google and others hope to turn everyone's
computer into a kiosk interface to access web
services. To a great extent, cellphones are
already that.
It's coming full circle, back to the model of the '60s and '70s
where users used terminals to access centralized systems.
On 8 Sep 2020 21:10:38 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
declaimed the following:
It's coming full circle, back to the model of the '60s and '70s
where users used terminals to access centralized systems.
It's the third coming... The second was the era of the X-server terminal which handled display functions for graphical client programs running on the mainframe(s).
And if theyI beg your pardon? We are not talking about microsoft.
can retrain tech insiders like yourself then I guess
they're doing a good job.:)
On 10/09/2020 13:38, Mayayana wrote:
And if they can retrain tech insiders like yourself then I guess
they're doing a good job.:)
I beg your pardon? We are not talking about microsoft.
Software as a services has always been a better idea from the
maintenance viewpoint, and the snoflake generation are too stupid
to own anything, so rented access to services is ideal for them.
Although I agree with what you say about the snowflake generation,
the problem is that the big boys want to make this the only choice.
Everyone gets the services, everyone gets the surveillance, everyone
gets frog-marched into their glorious vision of the Future.
It really is time for the new generation to read the classics like
Nineteen Eighty-Four, Brave New World, etc.
On 2020-09-10, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 10/09/2020 13:38, Mayayana wrote:
And if they can retrain tech insiders like yourself then I guess
they're doing a good job.:)
I beg your pardon? We are not talking about microsoft.
We're talking about Microsoft, we're talking about Apple,
we're talking about any tech giant that's enslaving the masses.
Software as a services has always been a better idea from the
maintenance viewpoint, and the snoflake generation are too stupid to
own anything, so rented access to services is ideal for them.
Although I agree with what you say about the snowflake generation, the problem is that the big boys want to make this the only choice. Everyone
gets the services, everyone gets the surveillance, everyone gets
frog-marched into their glorious vision of the Future.
It really is time for the new generation to read the classics like
Nineteen Eighty-Four, Brave New World, etc.
On Thu, 10 Sep 2020 16:33:04 +0000, Charlie Gibbs wrote:
Although I agree with what you say about the snowflake generation, the
problem is that the big boys want to make this the only choice. Everyone
gets the services, everyone gets the surveillance, everyone gets
frog-marched into their glorious vision of the Future.
It really is time for the new generation to read the classics like
Nineteen Eighty-Four, Brave New World, etc.
... and for good measure add in William Gibson's Sprawl trilogy
(Neuromancer, Count Zero and Mona Lisa Overdrive) and Neal Stephenson's "Snowcrash".
These were all written between 1982 and 1992, all predicting portable computers, mobile phones and the Internet as they now are, though
immersive 3D graphics and tactile interfaces are still lagging well
behind those books, but scammers, remote phishing exploits and system penetration are pretty much as predicted.
Or, if you want to go back in time, there's "The Machine Stops",
written by E.M. Forster in 1909. The main character uses a
communication device that looks a lot like an iPad.
"The Feeling of Power", written by Isaac Asimov in 1958, perfectly
predicted the atrophy of basic arithmetic skills.
The one thing these authors couldn't have predicted was the incredible
fall in the price of electronics - which made these dystopias not only possible, but arguably inevitable.
On 2020-09-10, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 10/09/2020 13:38, Mayayana wrote:
And if they can retrain tech insiders like yourself then I guess
they're doing a good job.:)
I beg your pardon? We are not talking about microsoft.
We're talking about Microsoft, we're talking about Apple,
we're talking about any tech giant that's enslaving the masses.
Software as a services has always been a better idea from the
maintenance viewpoint, and the snoflake generation are too stupid
to own anything, so rented access to services is ideal for them.
Although I agree with what you say about the snowflake generation,
the problem is that the big boys want to make this the only choice.
Everyone gets the services, everyone gets the surveillance, everyone
gets frog-marched into their glorious vision of the Future.
It really is time for the new generation to read the classics like
Nineteen Eighty-Four, Brave New World, etc.
The one thing these authors couldn't have predicted was the
incredible fall in the price of electronics - which made
these dystopias not only possible, but arguably inevitable.
The HP-35, IIRC the first scientific/engineering pocket calculator to be available, appeared in 1972. I still have a working HP-21, its successor, that I bought in 1976.
The point that really stood out on rereading it was the comment that it
takes much longer to build the computers that control the spaceships and missiles than the build the hulls and engines - exactly the opposite of
the current day when its faster and cheaper to build a car that uses
digital electronics to link its throttle pedal to the engine or to
control its gearbox than to fit a mechanical throttle linkage or use a mechanical automatic gearbox.
Everyone can't be an expert on everything.
Did "consumers" choose these things?
You missed my point entirely. I'm guessing there
are aspects of your life where you've been duped due
to ignorance. It's not realistic to think that everyone
should be expert on everything. That's why marketing
works. It doesn't excuse scammers. (Don't worry. I won't
tell anyone you paid $200 for your Lululemon glorified
pantyhose. :)
Just found a copy and reread it, and one thing Asimov didn't even
remotely forsee when he wrote that in the late 1950s was the low cost and >high speed with which solid state electronics could be churned out.
On 11/09/2020 01:51, Martin Gregorie wrote:
The HP-35, IIRC the first scientific/engineering pocket calculator to be
available, appeared in 1972. I still have a working HP-21, its successor,
that I bought in 1976.
And I have a linux app. :-)
On Fri, 11 Sep 2020 00:51:34 -0000 (UTC), Martin Gregorie <martin@mydomain.invalid> declaimed the following:state
Just found a copy and reread it, and one thing Asimov didn't evenWell... At that point in time, the consumer exposure to "solid
remotely forsee when he wrote that in the late 1950s was the low cost
and high speed with which solid state electronics could be churned out.
electronics" was the transistorized AM radio -- a radio powered by dryFile:Sanyo_M9998LU_Boombox.png
cell batteries and small enough to carry around! {And 20-25 years later, they've grown into these big bricks you have to lug around on your
shoulder
https://en.wikipedia.org/wiki/Boombox#/media/
}
My first was an HP-25, and the third was the HP-28 -- I don't
recall if the latter is in storage or self-destructed; the 25 died when
I couldn't get new battery packs (it was the only one I owned that
could be used at work, as it lost its mind when powered down... Working
in a black program is a pain.)
Are you new to the internet?
On Fri, 11 Sep 2020 13:10:31 -0400, Dennis Lee Bieber wrote:
My first was an HP-25, and the third was the HP-28 -- I don'tI discovered how to repair the HP-21 battery packs: split them open and replace the pair of AA size NiCd batteries. The inner case is just glued
recall if the latter is in storage or self-destructed; the 25 died when
I couldn't get new battery packs (it was the only one I owned that
could be used at work, as it lost its mind when powered down... Working
in a black program is a pain.)
to the textured removable base of the battery compartment and easily
enough removed with a sharp knife.
My latest effort, now that AA NiCds no longer exist, was more complex.
This time I fitted a pair of Perspex tubes as battery holders that each
take an AAA Sanyo Eneloop. These give longer runtimes between charges and
are still recharged by the original mains charger.
Everyone can't be an expert on everything. That's why
there are regulations to prevent scams. Even if people
love Facebook, Twitter, etc, that's no excuse that those
companies should be able to sell their personal data.
On 11/09/2020 01:51, Martin Gregorie wrote:Once written software costs nothing more than a ROM
The point that really stood out on rereading it was the comment that it
takes much longer to build the computers that control the spaceships and
missiles than the build the hulls and engines - exactly the opposite of
the current day when its faster and cheaper to build a car that uses
digital electronics to link its throttle pedal to the engine or to
control its gearbox than to fit a mechanical throttle linkage or use a
mechanical automatic gearbox.
Its not faster or cheaper at all, the exact opposite!
The reason for fly-by-wire throttle and electronic gearbox control is
driving dynamics, fuel economy and emissions control.
There is a lot of very expensive software in ECUs to get this right, and
it turns out even more expensive software to get it not right (if you
include fines and lawsuits).
---druck
"Martin Gregorie" <martin@mydomain.invalid> wrote
| > Did "consumers" choose these things?
| >
| Yes, they did!
|
| If they hadn't chosen to buy them, the business pushing them would have
| gone bust and their shitty products would no longer exist.
|
You missed my point entirely. I'm guessing there
are aspects of your life where you've been duped due
to ignorance. It's not realistic to think that everyone
should be expert on everything. That's why marketing
works. It doesn't excuse scammers. (Don't worry. I won't
tell anyone you paid $200 for your Lululemon glorified
pantyhose. :)
For someBe very careful of this. Fast chargers for nickel cells use the delta
applications, (Wahl series 4000 shavers, for example) a NiMH cell
of the same physical size can replace the original NiCD cell, (as
mentioned) the original charger still (at least the old
high-current type) works, and the NiMH provides about 3X the
shaves per charge compared to the original NiCD.
I've noticed that. Maybe it's partly my getting older,
but time and time again I see Millennials and Gen-Zers
who actually don't seem to be capable of thinking. They
make pronouncements based on arbitrary belief, then if
I question the validity of their statement, they switch
the context. It becomes clear that they're operating with
a seemingly sophisticated, yet entriely unexamined,
worldview.
I suppose they also haven't had much chance to defend
themselves from problems like Facebook. They've never
known the experience of their social life not being owned
by a for-profit company.
Quis custodiet ipsos custodes?
Nanny state is great if you can be sure Nanny is not owned by Facebook...Twitter...
There is no substitute for self awareness.
And personal attacks do not advance your cause.
Usually there is only one way out - revolution and guillotine.
Ideologies rule now in schools universities, social media - no
place for logic. If you do not agree, you are "Trump supporter"
I've noticed that. Maybe it's partly my getting older,
but time and time again I see Millennials and Gen-Zers
who actually don't seem to be capable of thinking. They
make pronouncements based on arbitrary belief, then if
I question the validity of their statement, they switch
the context. It becomes clear that they're operating with
a seemingly sophisticated, yet entriely unexamined,
worldview.
On Sat, 12 Sep 2020 08:08:12 +0200
Deloptes <deloptes@gmail.com> wrote:
Usually there is only one way out - revolution and guillotine.
Trouble with that is ... "Meet the new boss, same as the old boss".
The Natural Philosopher wrote:
Quis custodiet ipsos custodes?
Nanny state is great if you can be sure Nanny is not owned by
Facebook...Twitter...
There is no substitute for self awareness.
And personal attacks do not advance your cause.
Usually there is only one way out - revolution and guillotine. But be
careful "they" also know this and take care it would not happen to them.
On Sat, 12 Sep 2020 08:04:15 +0200
Deloptes <deloptes@gmail.com> wrote:
Ideologies rule now in schools universities, social media - no
place for logic. If you do not agree, you are "Trump supporter"
As they always have with varying intensity.
Trouble with that is ... "Meet the new boss, same as the old boss".
That does not work. Look t the French today. Absolutely no democracy
left, they all WANT to be run by a big State rather than a king.
On 2020-09-11, Martin Gregorie <martin@mydomain.invalid> wrote:
On Fri, 11 Sep 2020 13:10:31 -0400, Dennis Lee Bieber wrote:
My first was an HP-25, and the third was the HP-28 -- I don't recallI discovered how to repair the HP-21 battery packs: split them open and
if the latter is in storage or self-destructed; the 25 died when I
couldn't get new battery packs (it was the only one I owned that could
be used at work, as it lost its mind when powered down... Working in a
black program is a pain.)
replace the pair of AA size NiCd batteries. The inner case is just
glued to the textured removable base of the battery compartment and
easily enough removed with a sharp knife.
My latest effort, now that AA NiCds no longer exist, was more complex.
This time I fitted a pair of Perspex tubes as battery holders that each
take an AAA Sanyo Eneloop. These give longer runtimes between charges
and are still recharged by the original mains charger.
Were the replacement cells NiMH chemistry? For some applications, (Wahl series 4000 shavers, for example) a NiMH cell of the same physical size
can replace the original NiCD cell, (as mentioned) the original charger
still (at least the old high-current type) works, and the NiMH provides
about 3X the shaves per charge compared to the original NiCD.
I should have popped the battery holder out before I wrote that: my HP-21
is actually running on Maplins Hybrid AAA cells.
I don't know the exact chemistry, but its possibly a riff on NiMH.
Its certainly not NiMH as we used to know it because it holds charge at
least as well as NiCD did, while NiMH was famous for self-discharge:
On Sat, 12 Sep 2020 09:09:06 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
I should have popped the battery holder out before I wrote that: my HP-21
is actually running on Maplins Hybrid AAA cells.
I don't know the exact chemistry, but its possibly a riff on NiMH.
Its certainly not NiMH as we used to know it because it holds charge at
least as well as NiCD did, while NiMH was famous for self-discharge:
There is a low self-discharge variant of NiMH with slightly lower capacity and rated retention of around 80% over a year. In the shops they
get advertised as pre-charged or similar. I've been using them long enough
to wear some of them out (it took several years).
And aside from Jordan Peterson andThere are many, but Google changed the algorithms, so that you can not find them. Today you must know the names. Some 5 or 7y ago you could open
Camille Paglia, I haven't seen anyone with the conviction to
assess the emperor's new religion.
On 12/09/2020 01:59, Robert Riches wrote:
For someBe very careful of this. Fast chargers for nickel cells use the delta
applications, (Wahl series 4000 shavers, for example) a NiMH cell
of the same physical size can replace the original NiCD cell, (as
mentioned) the original charger still (at least the old
high-current type) works, and the NiMH provides about 3X the
shaves per charge compared to the original NiCD.
peak detection - a fully charged nickel cell will show a DROP in peak
voltage as it reaches full charge. This is detced to switch the fast
charger off.
The drop is far smaller on NiMH and sometimes not enough to switch the charger off..not good.
On 11/09/2020 14:06, druck wrote:
On 11/09/2020 01:51, Martin Gregorie wrote:Once written software costs nothing more than a ROM
The point that really stood out on rereading it was the comment that it
takes much longer to build the computers that control the spaceships and >>> missiles than the build the hulls and engines - exactly the opposite of
the current day when its faster and cheaper to build a car that uses
digital electronics to link its throttle pedal to the engine or to
control its gearbox than to fit a mechanical throttle linkage or use a
mechanical automatic gearbox.
Its not faster or cheaper at all, the exact opposite!
The reason for fly-by-wire throttle and electronic gearbox control is
driving dynamics, fuel economy and emissions control.
There is a lot of very expensive software in ECUs to get this right,
and it turns out even more expensive software to get it not right (if
you include fines and lawsuits).
And in fact the reason even the cheapest cars now have electric windows
is that it is lighter and cheaper to do it that way.
On 12/09/2020 05:02, The Natural Philosopher wrote:
On 11/09/2020 14:06, druck wrote:
On 11/09/2020 01:51, Martin Gregorie wrote:Once written software costs nothing more than a ROM
The point that really stood out on rereading it was the comment that it >>>> takes much longer to build the computers that control the spaceships
and
missiles than the build the hulls and engines - exactly the opposite of >>>> the current day when its faster and cheaper to build a car that uses
digital electronics to link its throttle pedal to the engine or to
control its gearbox than to fit a mechanical throttle linkage or use a >>>> mechanical automatic gearbox.
Its not faster or cheaper at all, the exact opposite!
The reason for fly-by-wire throttle and electronic gearbox control is
driving dynamics, fuel economy and emissions control.
There is a lot of very expensive software in ECUs to get this right,
and it turns out even more expensive software to get it not right (if
you include fines and lawsuits).
Oh the nativity! Modern ECU software is not in ROM, and will be modified
and re-flashed many times the lifetime of a car. Particularly when cheat modes need to be removed.
Huh????And in fact the reason even the cheapest cars now have electric
windows is that it is lighter and cheaper to do it that way.
But even more importantly it eliminates the need to safety test a second mechanism for each car design.
---druck
On 13/09/2020 11:01, druck wrote:
On 12/09/2020 05:02, The Natural Philosopher wrote:Flash memory or ROM, the point remains. Its cheap once you have written
Once written software costs nothing more than a ROM
Oh the nativity! Modern ECU software is not in ROM, and will be
modified and re-flashed many times the lifetime of a car. Particularly
when cheat modes need to be removed.
it.
On 13/09/2020 13:55, The Natural Philosopher wrote:
On 13/09/2020 11:01, druck wrote:
On 12/09/2020 05:02, The Natural Philosopher wrote:Flash memory or ROM, the point remains. Its cheap once you have
Once written software costs nothing more than a ROM
Oh the nativity! Modern ECU software is not in ROM, and will be
modified and re-flashed many times the lifetime of a car.
Particularly when cheat modes need to be removed.
written it.
Speaking as someone who was working in this area until recently, it
really doesn't.
---druck
How can a pattern cost money? software is essentially zero cost to
implement once it's been written.
Software is full of bugs.
In a safety- and/or security-critical context,
you can’t just ignore them, you need to find them (preferrably before someone else does), then recertify and redeploy the fixed software.
Certification is a moving target, at least in my industry, I don’t know about automotive. Same issues as above.
Security is a moving target; attacks keep getting better. Same issues
again.
And that’s before getting into changing customer needs, competitive challenges, rebranding, ...
The Natural Philosopher <tnp@invalid.invalid> writes:
How can a pattern cost money? software is essentially zero cost to
implement once it's been written.
Software is full of bugs. In a safety- and/or security-critical context,
you can’t just ignore them, you need to find them (preferrably before someone else does), then recertify and redeploy the fixed software.
On 14/09/2020 14:01, Richard Kettlewell wrote:
Software is full of bugs.
Yours may be.
When writing embedded code you make sure it isn't.
In a safety- and/or security-critical context,
you can’t just ignore them, you need to find them (preferrably before
someone else does), then recertify and redeploy the fixed software.
Certification is a moving target, at least in my industry, I don’t know
about automotive. Same issues as above.
Security is a moving target; attacks keep getting better. Same issues
again.
And that’s before getting into changing customer needs, competitive
challenges, rebranding, ...
In a car window winder?
On 15/09/2020 11:15, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:How much embedded programming have either of you done? I spent 5 years
On 14/09/2020 14:01, Richard Kettlewell wrote:
Software is full of bugs.
Yours may be.
When writing embedded code you make sure it isn't.
If you have a way to guarantee zero bugs in any nontrivial software, the
industry will beat a path to your door. Given you apparently can’t even
recognize a SQL injection vulnerability, I don’t think there’s much
chance of that happening any time soon.
In a safety- and/or security-critical context,
you can’t just ignore them, you need to find them (preferrably before >>>> someone else does), then recertify and redeploy the fixed software.
Certification is a moving target, at least in my industry, I don’t know >>>> about automotive. Same issues as above.
Security is a moving target; attacks keep getting better. Same issues
again.
And that’s before getting into changing customer needs, competitive
challenges, rebranding, ...
In a car window winder?
Bit more electronics in a car than just a window winder. At any rate
I’ll be trusting druck’s understanding of the costs and lifecycle or
automotive software over yours.
at it.
The Natural Philosopher <tnp@invalid.invalid> writes:
On 14/09/2020 14:01, Richard Kettlewell wrote:
Software is full of bugs.
Yours may be.
When writing embedded code you make sure it isn't.
If you have a way to guarantee zero bugs in any nontrivial software, the industry will beat a path to your door. Given you apparently can’t even recognize a SQL injection vulnerability, I don’t think there’s much chance of that happening any time soon.
In a safety- and/or security-critical context,
you can’t just ignore them, you need to find them (preferrably before
someone else does), then recertify and redeploy the fixed software.
Certification is a moving target, at least in my industry, I don’t know >>> about automotive. Same issues as above.
Security is a moving target; attacks keep getting better. Same issues
again.
And that’s before getting into changing customer needs, competitive
challenges, rebranding, ...
In a car window winder?
Bit more electronics in a car than just a window winder. At any rate
I’ll be trusting druck’s understanding of the costs and lifecycle or automotive software over yours.
Or about 5 man minutes or less per item manufactured.
How much embedded programming have either of you done? I spent 5 years
at it.
On 15/09/2020 11:31, The Natural Philosopher wrote:
On 15/09/2020 11:15, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
On 14/09/2020 14:01, Richard Kettlewell wrote:
In a safety- and/or security-critical context,
you can’t just ignore them, you need to find them (preferrably before >>>>> someone else does), then recertify and redeploy the fixed software.
Certification is a moving target, at least in my industry, I don’t know
about automotive. Same issues as above.
Security is a moving target; attacks keep getting better. Same issues >>>>> again.
And that’s before getting into changing customer needs, competitive >>>>> challenges, rebranding, ...
In a car window winder?
Bit more electronics in a car than just a window winder. At any rate
I’ll be trusting druck’s understanding of the costs and lifecycle or >>> automotive software over yours.
How much embedded programming have either of you done? I spent 5
years at it.
Look. My position is, and always has been, that *once the software has
been written*, the cost of deploying it is almost zero.
Neither you nor Druck have come up with more than in his case, proof
by assertion, and in your case, appeal to (his) authority, as to why
this is a false statement.
The Natural Philosopher wrote:
Or about 5 man minutes or less per item manufactured.
That would be something like 5 dollars per every single item.
Fortunately running your assumed numbers comes to a lot less than that.
The Natural Philosopher <tnp@invalid.invalid> writes:
On 15/09/2020 11:31, The Natural Philosopher wrote:
On 15/09/2020 11:15, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
On 14/09/2020 14:01, Richard Kettlewell wrote:
In a safety- and/or security-critical context,
you can’t just ignore them, you need to find them (preferrably before >>>>>> someone else does), then recertify and redeploy the fixed software. >>>>>>
Certification is a moving target, at least in my industry, I don’t know
about automotive. Same issues as above.
Security is a moving target; attacks keep getting better. Same issues >>>>>> again.
And that’s before getting into changing customer needs, competitive >>>>>> challenges, rebranding, ...
In a car window winder?
Bit more electronics in a car than just a window winder. At any rate
I’ll be trusting druck’s understanding of the costs and lifecycle or >>>> automotive software over yours.
How much embedded programming have either of you done? I spent 5
years at it.
Well, I’ve been contributing continuously to our product’s firmware for about half of the last decade, and intermittently since 2003 or so.
Look. My position is, and always has been, that *once the software has
been written*, the cost of deploying it is almost zero.
Neither you nor Druck have come up with more than in his case, proof
by assertion, and in your case, appeal to (his) authority, as to why
this is a false statement.
I think I’ve covered it in previous posts. Our product is subject to various standards-compliance and security requirements and these evolve continuously. Even just to stay still in the marketplace we have to
respond with new firmware versions from time to time. This isn’t an
unusual situation for anything with safety or security aspects and I’m
not sure what’s so hard to believe about it.
You haven't addressed a single one of my points.
The Natural Philosopher <tnp@invalid.invalid> writes:
You haven't addressed a single one of my points.
I have, twice, you’re just not reading the answers.
I've spent most of the last 33 years either writing it or testing it, in
the aviation, automotive, defence, accessibility, data security and most recently motorsport industries.
But hey, you obviously know best, this is the internet after all.
druck wrote:
I've spent most of the last 33 years either writing it or testing it, in
the aviation, automotive, defence, accessibility, data security and most
recently motorsport industries.
But hey, you obviously know best, this is the internet after all.
I think you are focusing on the development cost only.
No I wasn't, that's NP trying to move the goal posts of the discussion.
I was countering his assertion that fly-by-wire throttles and electronic controlled gear boxes are used because they are cheaper than the older mechanical systems.
Both the electronics and software control are vastly more expensive to develop and have higher per unit costs than simple throttle cables, or a mechanical gear linkages.
The reason they are used are to increase fuel economy, reduce emissions,
and to give the easier driving experience you expect of a modern car.
Most people would find a 30+ year old car without all these electronic
aids very difficult to drive, without the ECU compensating for engine temperatures, atmospheric conditions, fuel quality and load.
Find someone old enough to remember having to use the choke on a cold morning!
No I wasn't, that's NP trying to move the goal posts of the discussion.
I was countering his assertion that fly-by-wire throttles and electronic controlled gear boxes are used because they are cheaper than the older mechanical systems.
Both the electronics and software control are vastly more expensive to develop and have higher per unit costs than simple throttle cables, or a mechanical gear linkages.
The Natural Philosopher wrote:
That does not work. Look t the French today. Absolutely no democracy
left, they all WANT to be run by a big State rather than a king.
yes this is the result of bottom-up, but even worse is Sweden.
If you study the history you will see that Sweden is the experimental play ground for the left - you will also find out that the queen there betrayed her people and the British followed (paper money). Who did not follow, was removed from power.
Den 2020-09-12 kl. 11:11, skrev Deloptes:
The Natural Philosopher wrote:
That does not work. Look t the French today. Absolutely no democracy
left, they all WANT to be run by a big State rather than a king.
yes this is the result of bottom-up, but even worse is Sweden.
If you study the history you will see that Sweden is the experimental
play
ground for the left - you will also find out that the queen there
betrayed
her people and the British followed (paper money). Who did not follow,
was
removed from power.
What? I won't comment the playground thing more than if you are american
- you'll likely think all swedes are communists (even the
conservatives). But no - we are not.
What? I won't comment the playground thing more than if you are american
- you'll likely think all swedes are communists (even the
conservatives). But no - we are not.
And which queen was that?
The _only_ queen we had - of any relevance - was Kristina, which was in
the 1600s
On 18/10/2020 12:57, Bjrn Lundin wrote:
Den 2020-09-12 kl. 11:11, skrev Deloptes:
He's English. I thought the anti-Swede meme was that you had a stick upground for the left - you will also find out that the queen there
betrayed
her people and the British followed (paper money). Who did not
follow, was
removed from power.
What? I won't comment the playground thing more than if you are
american - you'll likely think all swedes are communists (even the
conservatives). But no - we are not.
your arse, bureaucratic, autistic spectrum, rule followers. Like in the
TV series "The Bridge", (Bron). Is that not right?
Even if it were true, you'd be amongst friends here.
Den 2020-09-12 kl. 11:11, skrev Deloptes:No At least I dont believe that and Im sure there alot fo others that
What? I won't comment the playground thing more than if you are american
- you'll likely think all swedes are communists (even the
conservatives). But no - we are not.
A quick Google reveals that Sweden introduced banknotes (paper money) in 1661, under Kristina. Presumably this was on TNP's radar
as we have
recently almost completely stopped using cash in the UK, due to Covid.
Paper money helped to enable government debt, but the UK built the
British Empire using debt so I don't know why TNP considers this a
betrayal. Perhaps he will explain?
Den 2020-09-12 kl. 11:11, skrev Deloptes:
The Natural Philosopher wrote:
That does not work. Look t the French today. Absolutely no democracy
left, they all WANT to be run by a big State rather than a king.
yes this is the result of bottom-up, but even worse is Sweden.
If you study the history you will see that Sweden is the experimental
play
ground for the left - you will also find out that the queen there
betrayed
her people and the British followed (paper money). Who did not follow,
was
removed from power.
What? I won't comment the playground thing more than if you are american
- you'll likely think all swedes are communists (even the
conservatives). But no - we are not.
And which queen was that?
The _only_ queen we had - of any relevance - was Kristina, which was in
the 1600s
I have no idea what you are taking about.
Nothing wrong with debt, but what is pernicious is no gold standard to
back it up.
Paper money is so easy to debauch to hyper inflation.
paper money is promise by the bank that you can get something with real
value in exchange.
That promise is empty, paper money is as much debt as electronic
money. The value of money (gold included) exists primarily in the belief
in its value backed by it being the only way to pay taxes.
The problem with gold as a basis of value is that it doesn't scale
with the fundamental source of value, which is the activity of people.
More people means more value in the world but not more gold.
There are many problems related to backing up with gold, but as I said it
is not about gold but any value.
On Tue, 20 Oct 2020 21:57:50 +0200
Deloptes <deloptes@gmail.com> wrote:
There are many problems related to backing up with gold, but as I said it
is not about gold but any value.
Right but the principle source of value is not rare metals it is
human activity. Using rare metals does not scale naturally to the real
source of value.
On 20/10/2020 22:50, Ahem A Rivet's Shot wrote:
On Tue, 20 Oct 2020 21:57:50 +0200
Deloptes <deloptes@gmail.com> wrote:
There are many problems related to backing up with gold, but as I said
it is not about gold but any value.
Right but the principle source of value is not rare metals it is
human activity. Using rare metals does not scale naturally to the real source of value.
That is not the point. Gold can not be multiplied infinitely. Paper
money can. It needn't be gold. Cowrie shells will do.
The technical need is for a mutually agreed proxy for value that is relatively indestructible and cannot be manufactured infinitely.
On 20/10/2020 22:50, Ahem A Rivet's Shot wrote:
On Tue, 20 Oct 2020 21:57:50 +0200That is not the point. Gold can not be multiplied infinitely. Paper
Deloptes <deloptes@gmail.com> wrote:
There are many problems related to backing up with gold, but as I said
it is not about gold but any value.
Right but the principle source of value is not rare metals it is
human activity. Using rare metals does not scale naturally to the real
source of value.
money can. It needn't be gold. Cowrie shells will do.
That there isn't enough gold is easily solved - make it more valuable.
The technical need is for a mutually agreed proxy for value that is relatively indestructible and cannot be manufactured infinitely.
Why ? Nobody uses such a thing any more, for most of my life and
the sky has not fallen in. As far as I can see we need a medium of
exchange whose quantity reflects the quantity of value available without constant revaluation.
On 2020-10-21, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 20/10/2020 22:50, Ahem A Rivet's Shot wrote:
On Tue, 20 Oct 2020 21:57:50 +0200That is not the point. Gold can not be multiplied infinitely. Paper
Deloptes <deloptes@gmail.com> wrote:
There are many problems related to backing up with gold, but as I said >>>> it is not about gold but any value.
Right but the principle source of value is not rare metals it is
human activity. Using rare metals does not scale naturally to the real
source of value.
money can. It needn't be gold. Cowrie shells will do.
That there isn't enough gold is easily solved - make it more valuable.
The technical need is for a mutually agreed proxy for value that is
relatively indestructible and cannot be manufactured infinitely.
Oh, the outlook will be sunny
In this land of milk and honey
When we print up lots of money:
That's the Social Credit plan.
But in case that starts inflation
And it might affect the nation,
Why we'll print another billion
Just as quickly as we can!
-- The Brothers In Law: Vote for Me
The technical need is for a mutually agreed proxy for value that isWhy ? Nobody uses such a thing any more, for most of my life and
relatively indestructible and cannot be manufactured infinitely.
the sky has not fallen in. As far as I can see we need a medium of exchange whose quantity reflects the quantity of value available without constant revaluation.
That there isn't enough gold is easily solved - make it more valuable.
Right but the principle source of value is not rare metals it is
human activity. Using rare metals does not scale naturally to the real
source of value.
Ahem A Rivet's Shot wrote:
Right but the principle source of value is not rare metals it is
human activity. Using rare metals does not scale naturally to the real source of value.
Why not?
Why ? Nobody uses such a thing any more, for most of my life andwhose quantity reflects the quantity of value
the sky has not fallen in. As far as I can see we need a medium of exchange
available without constant revaluation.
Because value can be created more easily than rare metals can be
created and so the value of the rare metal has to be steadily increased to compensate, which is a pity if the stuff is actually useful, but more to
the point cannot continue indefinitely.
Re: Re: Spectre / Meltdown06:07
By: Ahem A Rivet's Shot to The Natural Philosopher on Wed Oct 21 2020
amexchange
> Why ? Nobody uses such a thing any more, for most of my life and
> the sky has not fallen in. As far as I can see we need a medium of
> whose quantity reflects the quantity of valuein
> available without constant revaluation.
The economic situation of some places suggests the columns holding the sky
place are taking a very bad beating, so I'd buy a
good helmet if I were you.
Ahem A Rivet's Shot wrote:
Because value can be created more easily than rare metals can be
created and so the value of the rare metal has to be steadily increased
to compensate, which is a pity if the stuff is actually useful, but
more to the point cannot continue indefinitely.
Exactly this is the problem of our economic system - it seems to be
assuming infinite growth based on finite ressources, which contradiction
is hidden in the nature of fake money.
On Thu, 22 Oct 2020 07:42:40 +0200
Deloptes <deloptes@gmail.com> wrote:
Ahem A Rivet's Shot wrote:
Because value can be created more easily than rare metals can be
created and so the value of the rare metal has to be steadily increased
to compensate, which is a pity if the stuff is actually useful, but
more to the point cannot continue indefinitely.
Exactly this is the problem of our economic system - it seems to be
assuming infinite growth based on finite ressources, which contradiction
is hidden in the nature of fake money.
However gold standard and similar attempt to turn the economy into
a zero sum game which is equally false to fact.
floating money
but somehow we need to tie it to actual value which is
neither fixed nor infinitely extensible but rather somewhere in between.
There is no such thing as "real" money.
Exactly this is the problem of our economic system - it seems to be
assuming infinite growth based on finite ressources, which contradiction
is hidden in the nature of fake money.
On Thu, 22 Oct 2020 07:42:40 +0200, Deloptes wrote:
Exactly this is the problem of our economic system - it seems to beSeems a fair thumbnail summary, except that it's left out one important factor - the pathological greed shown by many people.
assuming infinite growth based on finite ressources, which contradiction
is hidden in the nature of fake money.
well that is insecurity for you. People who have known hunger and
deprivation eat themselves to obesity..
Its the same with money. And status, and power. Men with little dicks
become Napoleons, Hitlers or climate scientists.
The terminally useless become Marxists in order to blame their total inadequacy on *someone else* rather than take responsibility for it.
And so it all goes on. Human systems are supposed to be designed to
limit the damage such people can do to the species. I think we have
rather forgotten that.
However gold standard and similar attempt to turn the economy into
a zero sum game which is equally false to fact. We need the flexibility of floating money but somehow we need to tie it to actual value which is
neither fixed nor infinitely extensible but rather somewhere in between.
There is no such thing as "real" money.
Ahem A Rivet's Shot wrote:
However gold standard and similar attempt to turn the economy into
a zero sum game which is equally false to fact. We need the flexibility
of floating money but somehow we need to tie it to actual value which is neither fixed nor infinitely extensible but rather somewhere in between.
There is no such thing as "real" money.
you talk like philosopher - philosophies lead only to war :)
In fact most of the time in history economics worked with real money
(backed with real values) - even until 1971.
The truth is with automation and internet we are full power in the 6. Kondratiev wave
and somehow most of the people miss to understand what the
consequences are.
What we know will be obsoleted the same way the steam
engine was obsolete when the next wave came. It is obvious that it can not work the way we were doing it in the past 300y or even more years.
I hope we do not kill each other.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 70:23:02 |
| Calls: | 6,656 |
| Calls today: | 2 |
| Files: | 12,200 |
| Messages: | 5,332,148 |
| Posted today: | 1 |
