Erfahrungen mit Pkw Solar-Lader?...

[Rolf Bombach]

Eric Bruecklmeier schrieb:

Am 05.12.2022 um 21:54 schrieb Axel Berger:
Eric Bruecklmeier wrote:
Die Zeiten, in denen man einfach so die Batterie abklemmen kann, sind
definitiv vorbei.

Ernsthaft?

Ja

Nicht mehr wechseln?

lassen...

Kein Licht oder Radio für mehrere Tage
vergessen mehr?

Vergessen wird bei einem modernen Auto schwierig.

Tip: Wagen auf Beifahrerseite verlassen, ohne vorher
die Fahrertür geöffnet zu haben. Interessant, wie
das die Abschaltsequenz durcheinander bringt.

--
mfg Rolf Bombach

 

[Eric Bruecklmeier]

Am 14.12.2022 um 23:11 schrieb Rolf Bombach:

Eric Bruecklmeier schrieb:
Am 12.12.2022 um 21:37 schrieb Rolf Bombach:
Eric Bruecklmeier schrieb:
Am 05.12.2022 um 20:58 schrieb Rolf Bombach:

Kurzschlüsse kann man auch mit Sicherungen abfangen.

Im Prinzip ja, aber bei einem großen Bleiakku brauchts da schon eine
recht sportliche Trennfähigkeit.

Du meinst wegen drohender Bogenbildung? Die ist bei 12 V eher klein.
Auch heute werden ja Sicherungen eingesetzt.

Ja, die heutigen Sicherungen trennen aber nicht direkt ab Batterie,
die werden wohl kaum die Ströme beim Anwerfen eines 4l Diesels
abkönnen. Die Idee des pyrotechnischen Trennschalters ist aber, daß
die Karre ab Batterie spannungslos wird - natürlich erst nachdem
diverse Helferlein ausgelöst haben, damit braucht das Kastel ein wenig
Mindestfunktion mehr als eine Sicherung.

OK, zum Trennen aller Kreise direkt ist das eine saubere Lösung.

Eben.

Auch dürfte der Kurzschlussfall in z.B. einem Beleuchtungskreis
keinen Strom verursachen, welcher irgendwie in Konkurrenz zum
Akkuinnenwiderstand steht.

Bordelektrik besteht aber nicht nur aus Beleuchtungskreisen - siehe Oben.

Klar, im Anlasserkreis hat es keine Sicherung. Ausserdem weiss man nie,
was künftig hinzukommt. Eine elektrische Kat-Vorheizung beim Benziner
wird ja schon seit Jahren angedroht.

Beleuchtungskreis hatte ich nur erwähnt, als dass diese vernachlässigt
werden.
Gerade heute hier: Läppischer Auffahrunfall, auffahrender Lieferwagen nur
leicht eingedellt. Kurzschluss, Motorraum total ausgebrannt trotzt rascher
Löschbemühungen.

Eben.

In Europa gehen angeblich etwa 50(?) Fahrzeuge täglich
in Flammen auf, meist \"ohne erkennbaren Grund\". Ich vermute, da wurden
Cent-Beträge eingespart. Automobil-Subvention via Versicherung.

Ich finde die Idee gar nicht so schlecht, aber man kann natürlich auch
aus grundsätzlichen Überlegungen heraus jede neue Entwicklung ablehnen...

Du meinst, ich lehne Pyrotechnik ab?

Nein, aber bisweilen drängt sich der Eindruck auf, daß Du mit neueren
Entwicklungen eher grundsätzlich so Deine Probleme hast. Allerdings
wesentlich gemäßigter als bei einigen anderen hier ;-).

 

[Eric Bruecklmeier]

Am 14.12.2022 um 23:14 schrieb Rolf Bombach:

Eric Bruecklmeier schrieb:
Am 05.12.2022 um 21:54 schrieb Axel Berger:
Eric Bruecklmeier wrote:
Die Zeiten, in denen man einfach so die Batterie abklemmen kann, sind
definitiv vorbei.

Ernsthaft?

Ja

Nicht mehr wechseln?

lassen...

Kein Licht oder Radio für mehrere Tage
vergessen mehr?

Vergessen wird bei einem modernen Auto schwierig.

Tip: Wagen auf Beifahrerseite verlassen, ohne vorher
die Fahrertür geöffnet zu haben. Interessant, wie
das die Abschaltsequenz durcheinander bringt.

Bei meinem nicht - der merkt sogar, ob ich mich in oder neben der Karre
befinde und sperrt erst zu, wenn ich weggehe.

Jajajaja, da lassen sich jetzt wieder 110 Szenarien aufbauen, in denen
sowas kontraproduktiv ist. Ich finde es einfach geil. Wenn ich ohne
Helferlein unterwegs sein möchte, fahre ich Moped...

 

[Hanno Foest]

Am 05.01.23 um 17:48 schrieb Arno Welzel:

QA ist Teil der Entwicklung. Und nein \"Development\" meint *nicht*
\"Entwickler\" sondern die gesamte Abteilung, die sich um die Entwicklung
der Software kümmert - und ja, QA ist da auch ein Teil davon.

Ich will ja gar nicht ausschließen, daß es irgendwo Universalgenies
gibt, die das stemmen können, aber in der mir bekannten Praxis sieht das

Dazu braucht man keine \"Universalgenies\". Es genügt, wenn die
Entwicklungsabteilung auch eine Qualitätssicherung hat. Und ja - das
sind *verschiedene* Personen.

Also alles das gleiche wie vorher, bloß mit formal anderen
Abteilungsgrenzen? Super.

so aus, daß ich (unter anderem) seit knapp 30 Jahren Mailserver
administriere und das Wissen über email in der Entwicklung sich darauf
beschränkt, daß das Daten sind, die man dem Smarthost übergibt. Kein

Ja, was sollte der die Entwicklung auch mehr wissen, wenn die Anwendung
sich darauf beschränkt E-Mail zu senden. Die E-Mail muss formal korrekt
sein - was danach passiert, ist nicht mehr Sache der Anwendung.

An der formalen Korrektheit hapert es halt.

Wissen über rDNS, SPF, DKIM, inhaltliche Erwägungen, Bouncemanagement,
oder gar mögliche Fehlerzustände im realen Internet. Und wie will man
testen, wenn man nicht weiß, was in der Praxis alles schief gehen kann?

Man kann sich natürlich auf den Standpunkt stellen, daß es nicht das
Problem es Entwicklers ist, wenn Google die Mail nicht will, weil man
technisch alles richtig gemacht hat. Stimmt sogar irgendwo, ist aber dem
Geschäftsziel dennoch nicht dienlich.

Eine Anwendung kann exakt *nichts* daran ändern, wenn ein
fehlkonfigurierter Smarthost eine formal korrek eingelieferte Mail nicht
los wird.

Aber natürlich. Body nicht spammy aussehen lassen, auch extern
existierende Absenderadressen benutzen, nicht immer wieder an den
gleichen, nicht existierenden oder aus sonstwelchen Gründen Mail
ablehnenden Empfänger schreiben... (weil man kein Bouncemanagement hat,
oder es wegen mangelhafter Tests nicht funktioniert).

Ob rDNS, SPF und DKIM korrekt konfiguriert sind, ist das
Problem von Ops und nicht Dev.

Eine schöne Theorie eines Theoretikers

In der Praxis benutzt dann Dev den falschen Absender und/oder falschen
Smarthost, die Mail geht über den falschen Host raus und nichts paßt.
Und beim \"Testen\" ging alles, weil die Testmails intern geroutet wurden.
\"Wie, da ist ein Unterschied?\"

Und GMail ist *sehr* zickig bei der
Annahme, weil dank Spammer so gut wie gar nichts mehr akzeptiert wird,
was nicht von \"vertrauenswürdigen\" Quellen kommt. Wenn man über IPv4
einliefert, sind die Chancen höher - aber am Ende sucht man sich für
Transactional Mail lieber gleich einen Dienstleister dafür.

Funktioniert alles recht gut, sogar über IPv6. Zugegeben, ist nicht
immer einfach, aber Freenet und GMX haben das letzte Jahr über mehr
Probleme gemacht (ok, mag an der Kundenstruktur liegen).

Peinlich wird es dann, wenn man nicht mal merkt, daß die Mails nicht
ankommen, weil man die Bounces nicht will. \"Wie, Mail empfangen, es
stand nur senden im Pflichtenheft.\"

Das ist nicht \"peinlich\" sondern da hat derjenige, der die Anforderungen
aufgestellt hat, schlicht gepannt.

Klar - derjenige, der die Anforderungen aufstellt, weiß besser, wie
email funktioniert, als die Entwickler.

Lösung scheint es derzeit zu sein, email-Dienstleister als \"Smarthost\"
zu nehmen. Davon alleine funktioniert es zwar auch nicht besser, aber

Doch, für Transactional Mail funktionieren Dienstleister wie Mailjet,
Sendinblue etc. *viel* besser. Die verlangen nämlich Geld dafür und sind
daher für Spammer komplett uninteressant.

grep sendinblue client_access
# sendinblue.com
212.146.192.0/18 REJECT too much spam from sendinblue.com

Äh, ja, sicher.

Mailjet verschickte in den letzten Wochen auch ein paar Mal Spam, aber
da war ich mal nicht so, da die zumindest antworteten und den Eindruck
machten, was zu tun.

Deshalb ist die Zustellung
darüber auch deutlich problemloser als über irgendwelche gemieteten
Server bei Hostern, die GMail oder Microsoft als Spamschleuder einstuft.

Ranzkisten bei Hetzner, mit IPs, über die mglw. schon ein Dutzend Leute
drübergerutscht sind, sind ja auch eher die Spielzeugliga. Wo sollte der
Spam herkommen, wenn man seinen eigenen Adreßbereich hat, für den man
selber verantwortlich ist?

Andererseits hats Hetzner bei mir noch nicht in die Blockliste
geschafft. Waren jetzt aber aufgrund ihrer inkompetenten Abuse-Abteilung
ein paar Mal kurz davor. Wegen sowas:

\"Thank you for your abuse report.

We can only process your report by first forwarding them to our
customer. We cannot skip over this step. Your complaint cannot continue
forward unless it is first sent to the customer.\"

Ja, ihr mich auch.

dann existiert zumindest wieder eine unabhängige Instanz, die Feedback
geben kann, was da für Grütze angeliefert wird etc. Eine unabhängige
in-house QA hätte es natürlich genauso, und vermutlich billiger und
schneller, getan.

Was auch immer Du damit sagen willst. Meine Erfahrung nach ist das
Problem bei E-Mail *nicht*, dass Anwendungen etwas falsch machen,
sondern dass beteiligte Server falsch konfiguriert sind.

Das kann schon sein, daß es dir an Erfahrung mangelt, ja.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Hanno Foest]

Am 15.12.22 um 09:15 schrieb Eric Bruecklmeier:

[pyrotechnische Starterbatterietrennung]

Klar, im Anlasserkreis hat es keine Sicherung. Ausserdem weiss man nie,
was künftig hinzukommt. Eine elektrische Kat-Vorheizung beim Benziner
wird ja schon seit Jahren angedroht.

Beleuchtungskreis hatte ich nur erwähnt, als dass diese vernachlässigt
werden.
Gerade heute hier: Läppischer Auffahrunfall, auffahrender Lieferwagen nur
leicht eingedellt. Kurzschluss, Motorraum total ausgebrannt trotzt
rascher
Löschbemühungen.

Eben.

Ist ja gut und schön, aber gibt es auch Daten, ob der Sprengsatz im
Motorraum tatsächlich die Anzahl der Brände verringert? Und wie häufig
das Dings auslöst, insbesondere false positives? Und wieviel die
Reparatur kostet, natürlich.

Die Technik ist sicherlich nicht offensichtlich sinnlos, und spätestens
bei Antriebsbatterien von E-Autos möchte man sowas sicherlich haben.
Aber auf den ersten Blick sieht das nach einer Lösung aus, die
insbesondere geeignet ist, hohe Service- bzw. Ersatzteilkosten kosten zu
verursachen. Und ich halte es jetzt nicht für völlig abwegig,
Autoherstellern wirtschaftliches Handeln zu unterstellen :]

Als Beispiel aus der Vergangenheit denke ich da an

https://de.wikipedia.org/wiki/Procon-ten

Fragwürdiger Nutzen, aber zuverlässiger Totalschaden auch schon bei
kleineren Unfällen.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Wolfgang Martens]

Am Do.,15.12.22 um 12:38 schrieb Hanno Foest:

[pyrotechnische Starterbatterietrennung]

Die Technik ist sicherlich nicht offensichtlich sinnlos, und
spätestens bei Antriebsbatterien von E-Autos möchte man sowas
sicherlich haben. Aber auf den ersten Blick sieht das nach einer
Lösung aus, die insbesondere geeignet ist, hohe Service- bzw.
Ersatzteilkosten kosten zu verursachen. Und ich halte es jetzt
nicht für völlig abwegig, Autoherstellern wirtschaftliches Handeln
zu unterstellen :]

Als Beispiel aus der Vergangenheit denke ich da an

https://de.wikipedia.org/wiki/Procon-ten

Fragwürdiger Nutzen, aber zuverlässiger Totalschaden auch schon bei
kleineren Unfällen.

\"Bei einem Frontalaufprall wird in der Anfangsphase der Motorblock
zwischen den Vorderrädern hindurch in Richtung der Fahrgastzelle
geschoben. Durch die Umlenkung der Seile wird diese Bewegung genutzt,
um die Lenksäule und die Pedalerie in entgegengesetzter Richtung vom
Fahrer wegzuziehen und gleichzeitig die Sicherheitsgurte zu spannen.\"

Also wenn es nötig ist, dass das Auto vorne so weit zusammangedrückt
wird, dass sich der Motorblock in Richtung Fahrgastzelle bewegt um das
Procon-ten zu aktivieren, dann kommt der Totalschaden aber nicht vom
Procon-ten.

 

[Eric Bruecklmeier]

Am 15.12.2022 um 13:38 schrieb Hanno Foest:

Am 15.12.22 um 09:15 schrieb Eric Bruecklmeier:

[pyrotechnische Starterbatterietrennung]

Klar, im Anlasserkreis hat es keine Sicherung. Ausserdem weiss man nie,
was künftig hinzukommt. Eine elektrische Kat-Vorheizung beim Benziner
wird ja schon seit Jahren angedroht.

Beleuchtungskreis hatte ich nur erwähnt, als dass diese
vernachlässigt werden.
Gerade heute hier: Läppischer Auffahrunfall, auffahrender Lieferwagen
nur
leicht eingedellt. Kurzschluss, Motorraum total ausgebrannt trotzt
rascher
Löschbemühungen.

Eben.

Ist ja gut und schön, aber gibt es auch Daten, ob der Sprengsatz im
Motorraum tatsächlich die Anzahl der Brände verringert?

Keine Ahnung, aber da elektrisch verursachte Brände wohl recht häufig
auftreten, könnte ich mir einen Nutzen durchaus vorstellen.

Weder bin ich in der Branche tätig, noch verdiene ich an den Teilen
etwas. Es ging mir um die implizite Frage \"Warum nimmt man da nicht
einfach eine Sicherung?\". Eine Sicherung hat halt eine andere Aufgabe
als der beschriebene Trenner.

 

[Hanno Foest]

Am 15.12.22 um 13:53 schrieb Wolfgang Martens:

Als Beispiel aus der Vergangenheit denke ich da an

https://de.wikipedia.org/wiki/Procon-ten

Fragwürdiger Nutzen, aber zuverlässiger Totalschaden auch schon bei
 kleineren Unfällen.

\"Bei einem Frontalaufprall wird in der Anfangsphase der Motorblock
zwischen den Vorderrädern hindurch in Richtung der Fahrgastzelle
geschoben. Durch die Umlenkung der Seile wird diese Bewegung genutzt,
um die Lenksäule und die Pedalerie in entgegengesetzter Richtung vom
Fahrer wegzuziehen und gleichzeitig die Sicherheitsgurte zu spannen.\"

Also wenn es nötig ist, dass das Auto vorne so weit zusammangedrückt
wird, dass sich der Motorblock in Richtung Fahrgastzelle bewegt um das
Procon-ten zu aktivieren, dann kommt der Totalschaden aber nicht vom
Procon-ten.

Das Problem war, daß der Motor möglichst weit vorne sitzen mußte, damit
das System auch rechtzeitig auslöste. Entsprechend problematisch waren
dann auch kleinere Unfälle.

\"Since Audi was mounting its engines longitudinally and as close to the
front bumper as possible (\"in front of the headlights,\" to quote Jeremy
Clarkson), the \"no-airbag system\" worked even better than it should have.

In the event that the car would crash into something, the engine would
be one the first elements to be struck and pushed backward, toward the
cabin.\"

https://www.autoevolution.com/news/audi-procon-ten-the-no-airbag-safety-system-100087.html

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Hanno Foest]

Am 15.12.22 um 13:53 schrieb Eric Bruecklmeier:

Ist ja gut und schön, aber gibt es auch Daten, ob der Sprengsatz im
Motorraum tatsächlich die Anzahl der Brände verringert?

Keine Ahnung, aber da elektrisch verursachte Brände wohl recht häufig
auftreten, könnte ich mir einen Nutzen durchaus vorstellen.

Ich kann mir auch viel vorstellen, das hat aber nun mal nichts mit
echten Daten zu tun. Daß es nicht direkt unvorstellbar ist schrieb ich
ja bereits selber.

Weder bin ich in der Branche tätig, noch verdiene ich an den Teilen
etwas. Es ging mir um die implizite Frage \"Warum nimmt man da nicht
einfach eine Sicherung?\". Eine Sicherung hat halt eine andere Aufgabe
als der beschriebene Trenner.

Und mir ging es um die explizite Aussage in
<k003d8F7eopU1@mid.individual.net>, wo du einigen oder vielen
Gruppenteilnehmern pauschal Innovationsfeindlichkeit unterstellst.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Eric Bruecklmeier]

Am 15.12.2022 um 14:50 schrieb Hanno Foest:

> Ich kann mir auch viel vorstellen,

Na, das ist doch schön - gerade in der Adventszeit.

 

[Rupert Haselbeck]

Hanno Foest schrieb:

Und mir ging es um die explizite Aussage in
k003d8F7eopU1@mid.individual.net>, wo du einigen oder vielen
Gruppenteilnehmern pauschal Innovationsfeindlichkeit unterstellst.

Dieser Eindruck ist bei manchen hier aber nun wirklich nicht von der
Hand zu weisen. Manchmal gewinnt man den Eindruck, es ginge dem Autor
einfach nur darum, das ebenso alte wie falsche \"Früher war alles
besser!\" zu belegen.
Freilich muss nicht alles Neue per se gut und schön und lobenswert sein,
aber allzuoft kommt ein implizites \"Das ist neu und neu ist Mist\" durch.
Probates Beispiel seien wegen des allseits beliebten Automobilvergleichs
die immer wieder gern gebrachten unsäglichen Lobeshymnen nicht nur eines
einzelnen Posters in Bezug auf alte Stinker ohne all die höchst
gefährliche, fehleranfällige und auch sonst verderbliche Elektronik.
Gerade auch von Leuten, welche sich mit der Entwicklung von allerlei
elektronischen Gerätschaften ihr Geld verdienen (oder verdient haben)
klingt das nunmal eher, hmm, seltsam

MfG
Rupert

 

[Sieghard Schicktanz]

Hallo Arno,

Du schriebst am Thu, 5 Jan 2023 15:25:26 +0100:

Und bei vielem Neuen kommt wirklich erst mal Mist. Erst das
Geschäft, dann die Entwicklung. Und das nervt. Energiesparlampen,
Digital-Kameras, LED etc.

Das ist die aktuelle Methode, nennt sich \"DevOps\".

Da hast Du wohl etwas falsch verstanden.

Wenn, dann allerdings zumindest nicht nur ich.

DevOp steht für \"Development & Operations\" und bezeichnet die engere
Zusammenarbeit zwischen Entwicklung (Development) und Administration
(Operations).

Ja, meist in der Form, daß die \"Administration\" die Ergebnisse der
\"Entwicklung\" schon in frühen Stadien in die Hände bekommt und dann
damit die Kunden \"beglücken\" kann.

Motto: \"Release early, release often.\"

Wie kommst Du auf die Idee, dass das mit DevOp zu tun haben soll?

Weil\' s in dem Zusammenhang praktisch immer erwähnt wird, wenn man
was darüber hört oder liest. Und erwähnt wird als eine grundlegende
Vorgehensweise dabei.

Das geht zurück auf Eric S. Raymond und seinen Text \"Cathedral and the
Bazaar\", siehe auch:

Mag sein. Ob das eine gute Idee war?

> \"Release early. Release often. And listen to your customers.\"

Leider wird der _zweite_ Satz, wenigstens im kommerziellen Umfeld,
meistens nicht zitiert und ist deshalb dort wohl weniger bekannt.

Damit ist gemeint, dass man bei Software *häufiger* und mit *weniger*
Änderungen neue Versionen bereitstellen soll, damit
Kundenanforderungen frühzeitig berücksichtigt werden können und nicht
erst nach 6 oder 12 Monaten Entwicklungszeit.

Und damit implizierst Du, daß die (so) entwickelte Software schon _vor_
der wirklichen Fertigstellung (nach 6 oder 12 Monaten Entwicklungszeit)
dem Kunden zur Nutzung vorge, äh, legt werden soll, und erst später die
Funktion mit \"*häufige[n]* und mit [jeweils] *wenige[n]*\" Änderungen
allmählich zur vollen Funktion gebracht werden soll.

Und der zweite Satzteil heißt halt auf Deutsch: Das Produkt reift
beim Kunden, bei Software auch \"Bananen-Software\" genannt. Ist aber
nicht auf Software beschränkt...

Nein, das meint diese Aussage eben *nicht*.

Wie sonst könnte Deine vorstehende Einlassung realisiert werden?

(Kennst Du die \"Einführungsphase\" der ersten \"Model 3\" von Tesla?
Die haben das angeblich nach diesem Konzept durchgezogen.)

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Rolf Bombach]

Hanno Foest schrieb:

>>> https://de.wikipedia.org/wiki/Procon-ten

Andere Stimmen sagen, dass das eines der am meisten Sicherheit
bietenden Systeme war, es aber aus Kostengründen aufgegeben wurde.

Das Problem war, daß der Motor möglichst weit vorne sitzen mußte, damit das System auch rechtzeitig auslöste. Entsprechend problematisch waren dann auch kleinere Unfälle.

\"Since Audi was mounting its engines longitudinally ...

Praktisch alle Hecktriebler haben längs eingebaute Motoren
und es gibt auch andere Fronttriebler mit längs eingebautem Motor.
Je höher die Motorisierung, desto vollgestopfter der Motorraum, BTW.
(und damit korreliert auch die Geschwindigkeit des Aufpralls.)

....and as close to the front bumper as possible (\"in front of the headlights,\" to quote Jeremy Clarkson), the \"no-airbag system\" worked even better

than it should have.

In the event that the car would crash into something, the engine would be one the first elements to be struck and pushed backward, toward the cabin.\"

Französische Modelle hatten noch lange eine Kupplung
für eine Handkurbel. Die hat es auch bei kleinen
Unfällen durchs Getriebe in den Motor gedrückt, sozusagen.
Bei vielen Modellen ist die Motor-Getriebeeinheit hin
bei mittelmässigen Aufprallen.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Eric Bruecklmeier schrieb:

> Nein, aber bisweilen drängt sich der Eindruck auf, daß Du mit neueren Entwicklungen eher grundsätzlich so Deine Probleme hast. Allerdings wesentlich gemäßigter als bei einigen anderen hier ;-).

Ich bin halt kritisch. Das heisst nicht ablehnend.
Ausserdem ist mein Reflex, alles verbessern zu wollen,
irgendwie zwangsneurotisch. Allerdings sollte man
das von einem Ing/Sci auch erwarten.

Wenn ich was kritisiere, ist das also eigentlich ein gutes
Zeichen

Auch habe ich gewisse Vorbehalte gegen Leute, welche
ebenso zwangsneurotisch alles neuere als prinzipiell
besser wahrnehmen. Dass die Qualität gewisser Erzeugnisse
ihren Höhepunkt oftmals überschritten hat, ist durchaus
objektiv feststellbar.

Mir ist auch klar, dass early adopters wichtig für innovative
Firmen sind. Das ist für mich dennoch kein Ansporn, sofort
und immer das allerneuste iPhone zu kaufen, nur damit Firmen,
deren Haupteinnahmequellen das Nichtbezahlen von Steuern und
eventuell unklares Verwenden von Daten sind.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Eric Bruecklmeier schrieb:

Am 14.12.2022 um 23:14 schrieb Rolf Bombach:
Eric Bruecklmeier schrieb:

Vergessen wird bei einem modernen Auto schwierig.

Tip: Wagen auf Beifahrerseite verlassen, ohne vorher
die Fahrertür geöffnet zu haben. Interessant, wie
das die Abschaltsequenz durcheinander bringt.


Bei meinem nicht - der merkt sogar, ob ich mich in oder neben der Karre befinde und sperrt erst zu, wenn ich weggehe.

Zusperren ist nicht das Problem. Beim Insignia kapiert die Lichtsteuerung
dann nicht, dass ich weg bin und lässt das Standlicht an. Das ist durchaus
ein Problem. Es liegt nicht an der Technik als solcher, sondern an einer
offenbar fehlerhaften Implementierung. Das kann beim nächsten Modell wieder
ganz anders sein. Ansonsten sind alle diese Automatismen ja überaus praktisch.

> Jajajaja, da lassen sich jetzt wieder 110 Szenarien aufbauen, in denen sowas kontraproduktiv ist. Ich finde es einfach geil. Wenn ich ohne Helferlein unterwegs sein möchte, fahre ich Moped...

Irgendwie scheinst du die Technik als solche und deren Implementierung
nicht auseinanderhalten zu wollen.

Es geht um konkrete Bugs. Ich mag diese Assistenten durchaus. Aber
sie sollten korrekt implementiert sein. Und auch nicht missbräuchlich
eingesetzt werden, wie beim Dieselschummel. Aber das ist in EU/DE
offenbar nicht so wichtig, da die Automobilindustrie ganz offensichtlich
nicht der üblichen Gerichtsbarkeit untersteht.

Dazu kommt, dass nicht mehr so sorgfältig gearbeitet wird wie früher.
Kontrollieren, korrigieren, das ist selten geworden. Der Kunde als Tester.
Und alte Bugs, längst ausgerottet, kommen wieder zum Vorschein.

Aber das alles darf man ja nicht kritisieren, sonst ist man wieder ein
Ewiggestriger, der meint, früher wäre alles besser gewesen.

--
mfg Rolf Bombach

 

[Hanno Foest]

Am 15.12.22 um 18:54 schrieb Rolf Bombach:

https://de.wikipedia.org/wiki/Procon-ten

Andere Stimmen sagen, dass das eines der am meisten Sicherheit
bietenden Systeme war, es aber aus Kostengründen aufgegeben wurde.

Andersrum: Das System war billiger als die bei der Konkurrenz bereits
vorhandenen Airbags.

In the event that the car would crash into something, the engine would
be one the first elements to be struck and pushed backward, toward the
cabin.\"

Französische Modelle hatten noch lange eine Kupplung
für eine Handkurbel. Die hat es auch bei kleinen
Unfällen durchs Getriebe in den Motor gedrückt, sozusagen.
Bei vielen Modellen ist die Motor-Getriebeeinheit hin
bei mittelmässigen Aufprallen.

Kann schon sein, daß auch andere was falsch machen können, aber das ist
ja nun nicht die einzige Konkurrenz. Ich erinnere mich an Autos, die
sich mit reichlich zerknautschter Front und tropfendem Kühler noch vom
Unfallort davonschleppen konnten. Keine Ahnung, wie weit, und ob da noch
was zu retten war, aber Antrieb noch ok ist ja schon mal ein guter
erster Schritt.

Vorhin bin ich noch ein Forenposting von 2002 gestolpert, wo jemand
einen älteren Audi mit leichtem Frontschaden gekauft hatte und sich
wunderte, daß das Lenkrad so schlackerte. Antwort: Ist normal,
Procon-ten, Lenkung muß man komplett tauschen. Das war dann auch etwas
überraschend.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Arno Welzel]

Hanno Foest, 2023-01-05 18:41:

Am 05.01.23 um 17:48 schrieb Arno Welzel:

QA ist Teil der Entwicklung. Und nein \"Development\" meint *nicht*
\"Entwickler\" sondern die gesamte Abteilung, die sich um die Entwicklung
der Software kümmert - und ja, QA ist da auch ein Teil davon.

Ich will ja gar nicht ausschließen, daß es irgendwo Universalgenies
gibt, die das stemmen können, aber in der mir bekannten Praxis sieht das

Dazu braucht man keine \"Universalgenies\". Es genügt, wenn die
Entwicklungsabteilung auch eine Qualitätssicherung hat. Und ja - das
sind *verschiedene* Personen.

Also alles das gleiche wie vorher, bloß mit formal anderen
Abteilungsgrenzen? Super.

Der Unterschied ist, dass bei der Zusammenfassung von \"Entwicklern\" und
\"Qualitätssicherern\" in einer Abteilung auch eher zusammengearbeitet
wird. Die QA bekommt das Produkt nicht erst nach Monaten vorgelegt, wenn
es eigentlich schon fertig sein soll, sondern auch auf dem Weg dorthin,
z.B. alle 2-4 Wochen, um zu prüfen, ob die bisherigen Änderungen
Probleme verursachen.

[...]

Ja, was sollte der die Entwicklung auch mehr wissen, wenn die Anwendung
sich darauf beschränkt E-Mail zu senden. Die E-Mail muss formal korrekt
sein - was danach passiert, ist nicht mehr Sache der Anwendung.

An der formalen Korrektheit hapert es halt.

Die formalen Korrektheit einer E-Mail hat aber nichts damit zu tun, ob
man weiß, wie man rDNS, SPF oder DKIM konfiguriert.

[...]

Eine Anwendung kann exakt *nichts* daran ändern, wenn ein
fehlkonfigurierter Smarthost eine formal korrek eingelieferte Mail nicht
los wird.

Aber natürlich. Body nicht spammy aussehen lassen, auch extern
existierende Absenderadressen benutzen, nicht immer wieder an den
gleichen, nicht existierenden oder aus sonstwelchen Gründen Mail
ablehnenden Empfänger schreiben... (weil man kein Bouncemanagement hat,
oder es wegen mangelhafter Tests nicht funktioniert).

Für die Auswahl der richtigen Absenderadresse ist aber nicht die
Anwendung zuständig sondern die Person, die die Adresse festlegt. Und
auch \"spammy\" muss formal definierbar sein und nicht nur ein subjektives
Gefühl eines Mailserver-Admins - z.B. Test des Inhalts gegen
existierende Spamfilter.

Das Problem \"Mail an ablehnenden Empfänger schreiben\" zu lösen hat mit
der technischen Korrektheit Anwendung auch erstmal nichts zu tun. Die
Empfängeradresse muss auch jemand festlegen - aber das hat nichts damit
zu tun, ob die Anwendung technisch korrekt arbeitet.

Ob rDNS, SPF und DKIM korrekt konfiguriert sind, ist das
Problem von Ops und nicht Dev.

Eine schöne Theorie eines Theoretikers

Nein, Praxis. Wieso sollte die Entwicklung sich um die Nameserver und
Funktion des Mailservers, der die Header für DKIM signiert, kümmern?

In der Praxis benutzt dann Dev den falschen Absender und/oder falschen
Smarthost, die Mail geht über den falschen Host raus und nichts paßt.

In der Praxis hat der Dev nicht selbst zu entscheiden, welchen Smarthost
er wofür benutzt, sondern sich daran zu halten, was man ihm vorgibt.

[...]

Peinlich wird es dann, wenn man nicht mal merkt, daß die Mails nicht
ankommen, weil man die Bounces nicht will. \"Wie, Mail empfangen, es
stand nur senden im Pflichtenheft.\"

Das ist nicht \"peinlich\" sondern da hat derjenige, der die Anforderungen
aufgestellt hat, schlicht gepannt.

Klar - derjenige, der die Anforderungen aufstellt, weiß besser, wie
email funktioniert, als die Entwickler.

Ja, derjenige, der die Anforderungen stellt, weiß besser, wie *er*
E-Mail in der Anwendung nutzen will.

Und ja, es kann auch die Anforderung geben, dass eine Anwendung E-Mail
versenden soll *ohne* Prüfung, ob ein Bounce ausgelöst wurde, weil der
die Prüfung auf Bounces woanders passiert und ganz bewusst nicht in der
Anwendung. Die Welt ist nicht immer so schön schwarz/weiß wie man sie
sich manchmal vorstellt.

Wer etwas konkretes haben will, muss es auch so beschreiben. Deswegen
gibt es ja auch noch Softwarearchitekten und Produktmanager, die solche
Aspekte im Zweifelsfall hinterfragen - und ja, die sollten von der
Materie dann natürlich auch Ahnung haben.

[...]

Doch, für Transactional Mail funktionieren Dienstleister wie Mailjet,
Sendinblue etc. *viel* besser. Die verlangen nämlich Geld dafür und sind
daher für Spammer komplett uninteressant.

grep sendinblue client_access
# sendinblue.com
212.146.192.0/18 REJECT too much spam from sendinblue.com

Äh, ja, sicher.

Ja, sicher. Nur weil bei Dir so eine Regel existiert, bedeutet nicht,
dass das bei Anderen auch so ist.

[...]

dann existiert zumindest wieder eine unabhängige Instanz, die Feedback
geben kann, was da für Grütze angeliefert wird etc. Eine unabhängige
in-house QA hätte es natürlich genauso, und vermutlich billiger und
schneller, getan.

Was auch immer Du damit sagen willst. Meine Erfahrung nach ist das
Problem bei E-Mail *nicht*, dass Anwendungen etwas falsch machen,
sondern dass beteiligte Server falsch konfiguriert sind.

Das kann schon sein, daß es dir an Erfahrung mangelt, ja.

Möglich. Ich mache das erst seit etwa 20 Jahren.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Sieghard Schicktanz, 2023-01-05 21:44:

Hallo Arno,

Du schriebst am Thu, 5 Jan 2023 15:25:26 +0100:
[...]
Damit ist gemeint, dass man bei Software *häufiger* und mit *weniger*
Änderungen neue Versionen bereitstellen soll, damit
Kundenanforderungen frühzeitig berücksichtigt werden können und nicht
erst nach 6 oder 12 Monaten Entwicklungszeit.

Und damit implizierst Du, daß die (so) entwickelte Software schon _vor_
der wirklichen Fertigstellung (nach 6 oder 12 Monaten Entwicklungszeit)
dem Kunden zur Nutzung vorge, äh, legt werden soll, und erst später die
Funktion mit \"*häufige[n]* und mit [jeweils] *wenige[n]*\" Änderungen
allmählich zur vollen Funktion gebracht werden soll.

Nein, damit meine ich, dass man *neue* Funktionen nicht erst nach einem
Jahr kommen, sondern dann, wenn sie fertig und getestet sind.

Dass man Software generell schon anbieten soll, obwohl sie nicht
benutzbar ist, habe ich nicht behauptet.

Und der zweite Satzteil heißt halt auf Deutsch: Das Produkt reift
beim Kunden, bei Software auch \"Bananen-Software\" genannt. Ist aber
nicht auf Software beschränkt...

Nein, das meint diese Aussage eben *nicht*.

Wie sonst könnte Deine vorstehende Einlassung realisiert werden?

Dass man nicht erst eine Liste von 100 Änderungswünschen sammelt und
dann 1-2 Jahre entwickelt, sondern dafür sorgt, dass das Projekt
idealerweise nach *jeder* für sich unabhängig nutzbaren Änderung stabil
und auslieferbar ist.

(Kennst Du die \"Einführungsphase\" der ersten \"Model 3\" von Tesla?
Die haben das angeblich nach diesem Konzept durchgezogen.)

Was die Firmen von Musk angeblich irgendwie gemacht haben sollen, ist
mir herzlich egal. Weiterhin gab es bei Tesla keine Kunden, die ein
Fahrzeug mit konkreten Anforderungen beauftragt haben, die Tesla dann so
umgesetzt hat, sondern nur Herrn Musk, der mit dem Ding Geld verdienen
wollte.

--
Arno Welzel
https://arnowelzel.de

 

[Hanno Foest]

Am 06.01.23 um 03:25 schrieb Arno Welzel:

Ja, was sollte der die Entwicklung auch mehr wissen, wenn die Anwendung
sich darauf beschränkt E-Mail zu senden. Die E-Mail muss formal korrekt
sein - was danach passiert, ist nicht mehr Sache der Anwendung.

An der formalen Korrektheit hapert es halt.

Die formalen Korrektheit einer E-Mail hat aber nichts damit zu tun, ob
man weiß, wie man rDNS, SPF oder DKIM konfiguriert.

Steht da ja auch nicht.

[...]
Eine Anwendung kann exakt *nichts* daran ändern, wenn ein
fehlkonfigurierter Smarthost eine formal korrek eingelieferte Mail nicht
los wird.

Aber natürlich. Body nicht spammy aussehen lassen, auch extern
existierende Absenderadressen benutzen, nicht immer wieder an den
gleichen, nicht existierenden oder aus sonstwelchen Gründen Mail
ablehnenden Empfänger schreiben... (weil man kein Bouncemanagement hat,
oder es wegen mangelhafter Tests nicht funktioniert).

Für die Auswahl der richtigen Absenderadresse ist aber nicht die
Anwendung zuständig sondern die Person, die die Adresse festlegt.

Das ist nicht eine Adresse, sondern verschiedene, und bestimmt werden
die von der businesslogic. Rat mal, wer die schreibt...

Und
auch \"spammy\" muss formal definierbar sein und nicht nur ein subjektives
Gefühl eines Mailserver-Admins - z.B. Test des Inhalts gegen
existierende Spamfilter.

Klar ist das definierbar. Allerdings müßte erst mal jemand auf die Idee
kommen, daß das eine Rolle spielt und danach fragen. Probleme, die man
kennt, kann man angehen. Probleme, die man nicht kennt, werden nicht
angegangen.

Das Problem \"Mail an ablehnenden Empfänger schreiben\" zu lösen hat mit
der technischen Korrektheit Anwendung auch erstmal nichts zu tun. Die
Empfängeradresse muss auch jemand festlegen - aber das hat nichts damit
zu tun, ob die Anwendung technisch korrekt arbeitet.

Natürlich kann man völlig korrekt arbeitende email-Anwendungen
schreiben, die wegen wiederholten Versands an ablehnende
Empfänger-Adressen den Absender auf die Shitlist bringen. Ist dem
Geschäftsziel trotzdem nicht dienlich, und ich vermochte durchaus zu
kommunizieren, daß technische Korrektheit im Detail ohne Blick auf das
große Ganze nicht ausreicht.

Ob rDNS, SPF und DKIM korrekt konfiguriert sind, ist das
Problem von Ops und nicht Dev.

Eine schöne Theorie eines Theoretikers

Nein, Praxis. Wieso sollte die Entwicklung sich um die Nameserver und
Funktion des Mailservers, der die Header für DKIM signiert, kümmern?

Weil die Entwicklung überhaupt erst mal wissen muß, warum bzw. daß es
nicht gut ist, wenn man über den falschen Mailserver raussendet. Ohne
Verständnis der Zusammenhänge ist ihr das nämlich egal, und es geschieht
das zu Beobachtende.

Diese deine Haltung \"ich bin ein Fachidiot, ich muß nichts von den
Zusammenhängen verstehen und mich um nicht kümmern, ich bin einfach nur
codemonkey meinem Kämmerlein und guck nicht über den Tellerrand\" ist
genau das Problem.

In der Praxis benutzt dann Dev den falschen Absender und/oder falschen
Smarthost, die Mail geht über den falschen Host raus und nichts paßt.

In der Praxis hat der Dev nicht selbst zu entscheiden, welchen Smarthost
er wofür benutzt, sondern sich daran zu halten, was man ihm vorgibt.

In der Praxis codet der Dev die Businesslogic, die je nach
Geschäftsprozess unterschiedliche Absenderadressen benutzt. Guten Morgen.

[...]
Peinlich wird es dann, wenn man nicht mal merkt, daß die Mails nicht
ankommen, weil man die Bounces nicht will. \"Wie, Mail empfangen, es
stand nur senden im Pflichtenheft.\"

Das ist nicht \"peinlich\" sondern da hat derjenige, der die Anforderungen
aufgestellt hat, schlicht gepannt.

Klar - derjenige, der die Anforderungen aufstellt, weiß besser, wie
email funktioniert, als die Entwickler.

Ja, derjenige, der die Anforderungen stellt, weiß besser, wie *er*
E-Mail in der Anwendung nutzen will.

Da, wo Manna vom Himmel fällt, vielleicht. Derjenige, der die
Anforderungen stellt, möchte typischerweise, daß sich emails in der
Inbox des Kunden manifestieren, Details sind egal und könnten auch als
Magie beschreiben werden.

Wenn es gut \"agil\" läuft, vermögen ihm die Techniker Details zu
erklären, wie daß es nicht gut ist, Karteileichen bzw. gelöschte
Empfängeradressen nicht auszusortieren, so daß sie immer wieder im
Rahmen von Newslettern angeschrieben werden, während ihre Zahl steigt.
Dann kann man das Konzept interaktiv oder iterativ anpassen. Aber halt
nur, wenn die Techniker um die Probleme wissen und entsprechend Feedback
geben können.

[...]
Doch, für Transactional Mail funktionieren Dienstleister wie Mailjet,
Sendinblue etc. *viel* besser. Die verlangen nämlich Geld dafür und sind
daher für Spammer komplett uninteressant.

grep sendinblue client_access
# sendinblue.com
212.146.192.0/18 REJECT too much spam from sendinblue.com

Äh, ja, sicher.

Ja, sicher. Nur weil bei Dir so eine Regel existiert, bedeutet nicht,
dass das bei Anderen auch so ist.

Ist mir völlig egal, wie andere das handhaben und ob die ihren Spam
artig aufessen. Jedenfalls zeigt mir der ankommende Spam von Mailjet,
Sendinblue etc. daß \"für Spammer komplett uninteressant\" irgendwie
anders aussieht.

[...]
dann existiert zumindest wieder eine unabhängige Instanz, die Feedback
geben kann, was da für Grütze angeliefert wird etc. Eine unabhängige
in-house QA hätte es natürlich genauso, und vermutlich billiger und
schneller, getan.

Was auch immer Du damit sagen willst. Meine Erfahrung nach ist das
Problem bei E-Mail *nicht*, dass Anwendungen etwas falsch machen,
sondern dass beteiligte Server falsch konfiguriert sind.

Das kann schon sein, daß es dir an Erfahrung mangelt, ja.

Möglich. Ich mache das erst seit etwa 20 Jahren.

Man kann auch seit 20 Jahren stümpern.

Hanno

-
To make error is human. To propagate error to all server in automatic
way is #devops.
https://twitter.com/devops_borat/status/41587168870797312

 

[Sieghard Schicktanz]

Hallo Arno,

Du schriebst am Sun, 8 Jan 2023 01:45:35 +0100:

und dann 1-2 Jahre entwickelt, sondern dafür sorgt, dass das
Projekt idealerweise nach *jeder* für sich unabhängig nutzbaren
Änderung stabil und auslieferbar ist.

Was für die \"anderen\" Kunden halt bedeutet, daß sie _schon wieder_
eine neue Version kriegen, installieren _und testen_ müssen. Wenn
....
Das müssen sie ja nicht, wenn sie die Funktionen nicht brauchen. Sie

Wenn sie sich dessen sicher sind und _sein können_.
....

Oder installierst Du ein Betriebssystem auch jedes mal komplett neu,
nur weil Patches kommen?

Das ist ein vllig unpassender Bezug - die \"Patches\" eines
Betriebssystems _sind_ Installation(en) neuer Versionen von dessen
Anwendungsprogrammen.
Du sagst also, man kann ohne weiteres immer mal wieder solche
Aktualisierungen auslassen, obwohl die doch dafür sorgen sollen, daß
die _SICHERHEIT_ des Betriebssystems gewahrt bleibt.
Da stehst Du ziemlich alleine da, nach allem, was ich so mitbekomme.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------