Friday, November 25, 2016

Long-lasting designs

This is a reply to a post on YouTube discussing the longevity of Miranda-class ships in the fictional Star Trek universe.

Long-lasting old designs in various complex technology branches is really nothing new.

wrt this and the car industry, then off the top of my head, I can cite as examples the Volkswagen Beetle (1938–2003, 65y), the VW microbus (1949–2013, 64y), and Citroën 2CV (1948–1990, 42y).

Fiat 124 (1966) was transmogrified into Soviet Zhiguli/Lada cars, production of which design ended in 2012 in Russia, but continued well into 2014 in Egypt. With 2014 in mind, that's 48 years of mostly continuous production, though in that same year of 2014, the plant in Egypt had a fire

With trams, it's the PCC Streetcar (1936), numerous modifications of which are still in service. I don't know, whether any new PCC-spec trams are still built.

The Boeing B-52 Stratofortress had its first flight in 1952, and these planes are still in service.

Saturday, November 12, 2016

Most supernovae are misclassified as nebulae...

...Because the calculations reflecting the speed of light en route to Earth are off, since they don't take into account the effects caused by the confluence of time dilation and dark matter across the long trip that the photons take.

The title refers to numerous photos of nebulae, which I think are really supernovas in progress. I attribute this misclassification the the sheer distance involved and what I think are inaccurate speed-of-light calculations, because the distance between an event and Earth is so great. So, even a quick event in a galaxy far, far away just appears to happen very, very slowly when viewed from here. — So slowly for that matter, that the event looks to be in a standstill.

Dark matter, black holes, and other crazy theories

What I think dark matter is

Dark matter, in turn, is gravity from black holes (aka singularities) not (yet) manifest in this realm. These black holes are singularities, but not black holes, because they haven't opened up yet, but are close enough to the 'wall' separating them and this universe to cause gravimetric emissions. Alternately, I can describe dark matter as just a gravimetric echo of a black hole not yet manifest.

Imagine putting small magnet pieces on paper and then moving them around using a big magnet on the other side of that sheet of paper. The sheet of paper is that wall.

The black holes themselves don't open up just like that. A typical process in the lifetime of a manifest black hole is first to collect enough matter. And well, if there's no matter, then the singularity won't bother either.

But — if there's enough matter, the gravity of the non-manifest black hole (the 'dark matter') will collect the matter together. The right elements that are easier to attract will congregate into one or more masses, of which one such mass is large enough to be solar-forming.

The catch is, that black holes rotate, and the solar material basically chafes at the fabric of the 'wall' separating ths realm from what is probably another one. One possibility is, that a certain small amount of solar material moves from this realm through an inner back hole (inside a sun) to the other side. Well, enter pulsars. Some pulsars are long-lasting and stable, but emit solar material from the other side transmogrified into very powerful pulsar emissions.

Now, the stars and the suns are just pimples of the universe, which are mostly stable. In some cases, a star runs out of fuel (collected matter) and becomes a dwarf.

In other cases, there is some kind of an imbalance that causes a supernova to happen.

An open black hole sucks everything in; imagine a drain, and water going through it is just space. But in space, it's totally 3-dimensional. |There might be more dimensions.|

For a supernova, one option is, that as the amount of solar material increases, a black hole within the stellar object gets more powerful (and maybe sucks more in). Or that it is sustained, along with the star around it. Once the stellar object runs out of fuel, the opening of the singularity inner to the stellar object cannot be sustained, and as that singularity leaves its 'nest' and closes within the stellar object, the remaining solar material that has so far made up that stellar object — unable to be to be sucked in anywhere — disperses. Often violently.

Imagine a rubber balloon and then applying pressure from its hind end. Apply too much pressure, and the ballooon pops. The rubber pieces of the balloon fly around quickly and sometimes violently, as they hit stuff in their way.

13.11.2016 update.

I later thought about actual open black holes that don't have any light around them. As I'd described stars as pimples of the universe, then I could think of not just one type of supernova, but more than one.

So, one type of supernova is likely to be caused by dispersing solar (and other) matter once a singularity has closed up, but the collected matter around the closing doesn't have anywhere to move. That's described above. To add to that, such a nova happens, if the closing is not safe, or if there's surplus material and gravity, and maybe an imbalance involved, but the hole itself closes.

The other type of supernova is caused by a tear in the continuum. The magnets and paper description might come into play here, as rotating black holes are covered by stars (note, that manifest singularities are circular, but instead of forming a mass, they are 3D drains when open), which avoid, prevent or delay the tear from happening.

So it could be, that a certain star runs out of fuel, but a greater imbalance causes the black hole to manifest.
What may be causes to the imbalance, are unknown. Perhaps lack of sufficent matter to close the hole, if the singularity is too powerful. In that case, it's not so much solar matter exploding outwards, but a violent opening, whereby normal gravity is pushed away, in the process also pushing outwards, but not destroying/extinguishing all extant matter that is in the way. That is disperesed before the hole opens.

At this point, I'm too tired, and the previous paragraph is too illogical even to me. I'd rather read up on Wikipedia about actual discoveries and proofs, but later.

All this from the crazy theories dept. I felt so giddy this hour, that I wanted to put out something off the wall with lots of non-sensical technobabble.

Added minor wording and idea updates a few days later.

Saturday, November 5, 2016

Postimees ja vana Android

See on (algselt kiirena kirjutatud) täiendus varasemale postitusele, mis kritiseeris Postimees Online (edaspidi PMO) uue mobiiliversiooni kasutatavust, kus peamiseid kriitikanooli sai sisu liigtihe automaatne uuestilaadimine.
Üldse, kui sinu hallata on suure levikuga veebileht, siis üks suuremaid vigu on [kogu] lehekülje sisu automaatne uuestilaadimine, sest kasutaja pole seda ise soovinud, ning mobiiliseadmetes kulutab see akut.
Antud blogipostitus on mõeldud kõigile neile inimestele, kelle mobiiliseade (telefon või tahvelarvuti) on varustatud Android 2.3 "Gingerbread" opsüsteemiga, mida pole võimalik uuendada, ning mille vaikimisi lehitseja on liiga vana ja aegunud, et oleks võimalik Postimehe veebilehelt mugavalt uudiseid lugeda. Või üldse.

Ehkki seesinase fookus on Postimehe koduleht, võimaldavad allpool pakutud lahendused laiemalt külastada teisigi kaasaegseid Interneti-lehekülgi, mis Androidi (2.3 ja vanemate) vaikimisi lehitsejas ei näita või pole enam toetatud.

Juhised nõuavad mõnetist tehnika-alast oskust, kuid leian, et instruktsioonides ei tohiks midagi väga keerulist olla.


Probleemid:
* Android 2.3 on vana ja Postimehe enda äpp võib-olla näitab, võib-olla mitte, aga tegemist on äpiümbrisega (wrapperiga), mis põhimõtteliselt näitab Postimehe kodulehte sisseehitatud vaikimisi veebimootoriga. Postimehe äppi pole tegelikult vaja.
* Android 2.3-s vaikimisi lehitseja on liiga vana, et kogu seda sisu adekvaatselt näidata, sest selle lehitseja umbes viis aastat vana veebimootor on lootusetult aegunud.

Mida teha:
* Tõmmata peale Firefox Androidile.
ARMv7l protsessoriarhitektuuril käiatava Android 2.3 jaoks on kõige uuem Firefoxi versioon 47.0; selle eestikeelse variandi saab tõmmata Mozilla FTP lehelt või Google Play Poest.

Mozilla enam ei arenda Android 2.3 jaoks Firefox-i, nii et Google Play Poes võib Firefox olla vabalt märgitud kui ühildumatu. Siis tuleb tõmmata Firefoxi APK-installer eraldi Mozilla FTP-lehelt ja enne selle installimist lubada ajutiseks Androidi seadetes kolmandatest allikatest installimise võimalus ehk mitte-Marketist/Play Poest.

Asja parem külg on see, et vanale mobiili-opsüsteemile siiski on saadaval modernne lehitseja, millega saab vaadata kaasaegseid veebilehti.
* Et PMO mobiiliversiooni sisu laeb liiga tihti, tuleb kasutada PMO töölaua-versiooni. Viimases töötab siis ka artiklite kommentaaride hindamise funktsioon. Ehkki Firefoxi äpi-menüüst on võimalik valida "Töölaua-versioon", tekib ikkagi kaks probleemi:
** PMO lehtede jaoks tuleb Firefoxi töölaua-vaadet valida menüüst iga kord peale Firefoxi käivitamist või peale lehitsejas uue vahekaardi avamist.
** Teiseks on PMO töölaua-versiooni küljendus mõeldud töölauale, aga kunagi töötas see väga ilusti mobiiliversioonina. Vaadet on võimalik näppudega suurendada. Need liigutused on tüütud ja ajakulukad.

Lahendused:
1. Oletades, et sinu Firefoxi versioon on 47.0 (nagu üleval kirjas, Android 2.3-le kõige hiljutisem), jäta allolev vahele ja mine edasi järgmisele punktile.
Kui sa oma Firefoxi versiooni ei tea, otsi see üles: Lähed Firefoxis about: lehele, kus see kribukirjas näha on. Jäta see versioon meelde; tähtis on see kujul 47.0 (täisarv-punkt-null).

Ise kasutan Firefoxil põhinevat IseCat lehitsejat; Android 2.3-le on IceCat-i uusim versioon 38.8.0.
2. Edasi tuleb minna aadressiriba kaudu lehele about:config — seal on kõik Firefoxi tähtsamad seaded, mis on käsitsi seatavad;
1.1 puutuda seal suurt pluss-märki ja kirjutada nimelahtrisse

general.useragent.overrride.postimees.ee

1.2 Puutuda nuppu "tõeväärtus", vali "string"
1.3 "Sisesta string" lahtris lisa järgmine user-agent string (lehitseja versioon, mille lehitseja saadab seatud leheküljele, antud juhul postimees.ee) —

Mozilla/5.0 (X11; Linux armv7l; rv:47.0) Gecko/47.0 Firefox 47.0

Kui telefonis on Android 2.2, või kui telefonis ka on Android 2.3, aga protsessoriarhitektuur ARMv6, siis nende jaoks on uusim Firefox hoopis versioon 31.3.0esr. Siis peaks kasutajastring olema selline:

Mozilla/5.0 (X11; Linux armv6; rv:31.0) Gecko/31.0 Firefox 31.0

1.4 Olles sobiva kasutajastringi sisestanud, vajuta nupule "Loo".
Antud string kehtib ainult Firefox 47.0 kohta. Kui sinu Firefoxi versioon on erinev, peaksid lisama selle, mis sul on.

Kogu see tegevus seab postimees.ee domeenile töölaua-põhise lehitsejastringi (i.k. user-agent string) nii, et Postimehe koduleht saadab Firefoxi-mobiililehitsejale töölaua-versiooni.

Ülal väljatoodud kasutajastringis tähendab näiteks X11 Unix-põhiste opsüsteemide graafilist keskkonda, Linux tähistab opsüsteemi nime (sh samanimelist kernelit, mis on Androidis sees), armv7l mobiiliseadme keskprotsessori tüüpi, rv: ja Gecko tähistavad Gecko veebimootori (mida kasutavad Firefox, IceCat jt lehitsejad) versiooni, selle järel lehitseja enda nimi (siin vastavalt Firefox) ja versioon.
3. Aga see pole veel kõik, sest Postimehe töölaua-versioon mobiilis ju päris korralikult ei näita, sest pisikesel ekraanil on töölauaversioon liiga lai, tekst liiga väike, ning tuleks liiga palju suurendada.

Et vähemalt enda jaoks probleemi kiiresti lahendada, tegin järgmist:

Installisin Firefoxile laienduse nimega Stylish. Sellega on võimalik muuta lehitsejas näidatavate lehekülgede välimust läbi mobiiliseadmesse tõmmatud kasutajastiilide (i.k. userstyles).
Stylish laiendus töötab nii, et lehitseja tõmbab mõne lehekülje kasutaja seadmesse ja seejärel rakendab Stylish leheküljele seatud kasutajastiilis oleva küljenduse. Lehekülje originaalvälimus jääb lähtekohas ikka samaks, st. kogu see välimuse muutmise protsess toimub ainult kasutaja seadmes, kui kasutaja on mõnele lehekülje mugavama kasutamise tarvis tõmmanud kasutajastiili.
Edasi veetsin selle aasta kevadel mitu ööd ja päeva uurides töölaua-Firefoxi arendajatööriistade abil Postimehe lähtekoodi ja kirjutasin oma stiililehe, et nö tagasi saada mobiilide jaoks mõeldud klassikaline välimus.

Et kõik teisedki inimesed saaksid seda stiililehte kasutada, panin kasutajastiili üles GitHubi:

https://github.com/juneyourtech/GM_PM/raw/master/PM_mobile_classic.css

1. Kopeerida ülalolev aadress.
2. Firefoxis minna läbi Lisade lehekülje Stylish alamlehele: Menüü [> Veel >] Lisad > Stylish;
3. Vajuta "Halda stiile" nupule;
4. Vajuta nupule "Install from URLs", aseta tekstiväljale ülalolev kopeeritud aadress. Vajuta Sobib/OK, kirjuta lisaks stiili nimi.
5. Postimehe töölaua-versioon peaks sestpeale olema nähtav mobiilidele sobilikul kujul.
6. Edaspidi tuleks eelistada Postimehe www-aadressi kujul www.postimees.ee

Ei garanteeri, et see kasutajastiil töötab kõigi peamiste Postimehe alamlehtedega (eriti Ilmajaam).

Reklaame see kasutajastiil otseselt ei blokeeri, kuid üldiselt olen lähtunud sellest, et Firefoxile Androidil on peale installitud skripte blokeeriv NoScript Anywhere laiendus, milles on antud postituse teemat silmas pidades lubatud peamiselt postimees.ee ja pmo.ee domeenid.
Tavalisest reklaamiblokeerijast, nagu Adblock Plus vms., on NoScript mitu korda efektiivsem ja vähem ressursinõudlik; leheküljed laevad kiiremini, ning selles oleva valge nimekirja abil on lubatud ainult need domeenid/võrgulehed, mida vaja.

Inimestele läheb korda telefoni või tahvelarvuti akutarve. Skriptide blokeerimine lehitsejas säästab nii aega, akut, ning mobiil-Interneti kasutajatel ka raha.
Läbides kõik need sammud ongi võimalik Android 2.3 opsüsteemis saada endale võimalus normaalselt lugeda Postimehe uudiseid ja hinnata artiklite kommentaare.


Veidi ajaloost:

Valmistehtud stiililehe esialgne tulemus oli rahuldav, kuid alguses ei olnud mul veel õiget lahendust, mille abil olnuks võimalik PMO töölauaversiooni probleemivabalt kätte saada, isegi kui teatud olukordades paistis disain töötavat.

Hiliskevadel või suvel tõmbasin eksperimenteerimise käigus peale Firefoxil põhineva GNU IceCat lehitseja, millel pooljuhuslikult avastasin kasutajastringi muutmise võimaluse, ning ka selle, et erinevat kasutajastringi on võimalik seadistada erinevatele saitidele.

Sügisel avastasin lõpuks, et ka Firefox toetab sama funktsionaalsust; lihtsalt on see about:config lehel iseenesest mitteeksisteeriv ja user-agent string tuleb ise lisada.

Tuesday, November 1, 2016

CSS3: Match parameter contents with the :not pseudoclass

It's possible to match parameter contents in the :not (negation) pseudoclass used in Cascading Style Sheets Level 3 —

A:not([href*="subdomain.domain.tld"]) {color:blue;}

All links are colored blue except those targeting anything that contains subdomain.domain.tld .

The asterisk * before the equals sign = means, that the match is any parameter value inside double quotes (quotes may be optional or pursuant to syntax) — in this case, links (A) that contain subdomain.domain.tld — to which a particular CSS rule is not applied using :not([]). Here, link contents can be a variation of
https://subdomain.domain.tld/directory/folder/file.html

More complex use of the :not pseudoclass:

A[TARGET="_blank"]:not([href*="subdomain.domain.tld"]) SPAN {color:yellow}

All SPAN elements inside links (A) with TARGET="_blank" (these typically open new windows) are colored yellow; except those, where link address contents match subdomain.domain.tld

Approximation in HTML:
<A HREF="https://domain.tld" TARGET="_blank"><SPAN>Text in this link's SPAN element is colored yellow.</SPAN></A>

<A HREF="https://subdomain.domain.tld/folder/file.html" TARGET="_blank"><SPAN>
Text in this link's SPAN element is not colored yellow, because it matches subdomain.domain.tld .</SPAN></A>
The W3C CSS3 spec itself is rather fuzzy about all this, but after some experimenting, I got a satisfactory result with a userstyle.

And if it works in a modern version of Firefox, it should work in other browsers, too.

Additional notes

If you want to match by the existence of a parameter inside an element, such as ENABLED inside <BUTTON>, or use a simple selector, such as a .classSelector or #idSelector — then you have to do without square brackets []:
A:not(TITLE) {}
   /* all links that do not contain TITLE
      (without tooltips on link hover) */

BUTTON:not(DISABLED) {}
   /* all buttons that are enabled */

DIV:not(.frontpage) {}
   /* all DIV elements not with class="frontpage" */

DIV:not(#articleContents) {}
   /* all DIV elements not with id="articleContents" */
...and so on.

Other selector matching rules apply, too.

Errata

Strangely enough, I found it impossible to insert or nest a negation pseudoclass into a series of combining selectors (with Firefox 39.0.3):

DIV A:not([href*="subdomain.domain"]) SPAN {parameter:value;}

— where a multi-selector involving SPAN elements inside links without subdomain.domain and inside DIV elements would not work.

So, in a ruleset, the negation pseudoclass must be listed first, and can include child selectors, but cannot be a child selector itself.

Rationale

As it was, this post was borne out of a need in a userstyle (made to improve the functionality of one website) to give all links that open in new windows using TARGET="_blank" a certain visible background, which was a yellow gradient, so that the reader could decide how they should open those links.

The exception to that rule was to avoid setting that background to weather content, as it was based on elements for which the website applied its own background images. Incidentally, these backgrounds were dynamically applied to child elements inside links with TARGET="_blank", and setting one's custom background replaced the background images, and weather information was thus lost.

As the links resolved to the website's weather subsite, then excluding those required matching the weather-themed subdomain, as in weather.website.tld and the links' SPAN, B, and other child elements that already contained backgrounds.

Of course, I could have specifically targeted several large and content-heavy parent DIV elements that did not contain weather content, but this would certainly have required involving way more than one such DIV element.

I could have also tried using a negation pseudoclass with a simple selector, as in:

DIV:not(.thisclass) A[TARGET="_blank"] {background:gradient(to left, yellow 0px...)}

... and maybe this would have worked, too. — But then I would have risked missing several non-weather links that did open in new windows, and as such, these would in turn have remained potentially invisible.

Therefore I found it more prudent to use link-based selectors.

Article Errata:
Corrected terminology of :not being a pseudoclass instead of a pseudoelement.

Finding the classic Netscape/Mozilla hand cursor

If there is anyone who remembers using Netscape (oh, the good times), they will also remeber the business-like hand cursor that appeared on hovering over links. This cursor is a classic.

Now, originally, the cursor was available at this address:
http://lxr.mozilla.org/mozilla/source/widget/src/build/res/select.cur?raw=1

Alas, that resource is not available anymore.

And whilst
https://dxr.mozilla.org/mozilla1.8/source/widget/src/build/res/select.cur
also exists, I'd found no way to download it.

So, as I was googling (yes, I still..sometimes do that) this classic hand cursor with the
/mozilla/source/widget/src/build/res/select.cur
search string —

I found this awesome resource on GitHub:
https://github.com/krad-radio/mozilla-krad/blob/master/widget/src/build/res/select.cur
Apparently and for reasons unknown, a software developer took the classic Mozilla source and wanted to improve it.
The download link was there all right, so I got my favourite cursor.

License information

As the original Mozilla Application Suite was licensed under the Mozilla MPL/NPL/LGPL tri-license, then this should apply to the subject image shown at the top of this post.

Thursday, October 27, 2016

YouTube video stuttering in Firefox

This post concerns a relatively specific hardware and software setup.

I have a nine-year-old computer that has just 1 Gb of RAM (yes, one gigabyte), a one-core CPU and an integrated Intel video adapter. The operating system is Windows XP SP3.

In that computer, the default browser is Firefox because of its much lower memory footprint compared to other major browsers; and the version of Firefox is 39.0.3, as it's the last one with which Flash videos (off YouTube) are played back without stuttering much. That older version of Firefox also supports cookie prompts, which were removed in Firefox 44 or 45.

For that non-stutter to happen, I must set the process priority Above Normal for Firefox's plugin-container.exe program in Process Explorer (the latter is a fancy task manager; I usually have it on all the time).

So far, all this has worked nicely with Flash extended support releases (ESRs, currently at 18.x.x.x branch) up until version 18.0.0.266; I haven't tested with newer Flash versions yet.

Caveat: This setup didn't seem to work properly on a newer computer with the same OS and more RAM (wherein Flash stuttering in Firefox was much lesser, btw), apparently causing slowdowns with heavy CPU usage and other issues. I never quite found out what the exact cause was, but upping plugin-container priority might have been it.

IIRC, Linux seems to have that stuttering issue solved with Firefox and HTML5 video playback and a fresh profile. At least I don't remember any stuttering issues in Linux.
Strangely enough, resource usage scenarios are different between Windows and Flash vis-a-vis Linux an HTML5: In Linux, HTML5 video playback does not seem to consume a lot of resources on its own; whereas HTML5 video playback with the aforementioned Windows configuration is very resource-intensive, while Flash playback is reasonable in terms of CPU usage.
Other settings of note that decrease Firefox memory/CPU consumption:
(There's an older blogpost that I've considered updating. Might as well put all this into a completely new post to reflect the times, since many long years have passed in-between.)
In about:config

browser.sessionstore.interval is set to 600000. This interval changes the frequency of session saves.
browser.sessionhistory.max_entries (current browsing history per tab) is set to 25 instead of 50.
browser.sessionhistory.max_total_viewers is set to 0.
nglayout.initialpaint.delay is set to 0. The default non-zero value allows the Gecko layout engine to wait a while until a major part of a page is loaded. The setting of 0 can be more CPU-intensive, but I sometimes prefer seeing a complex page load early.
For very long and complex pages that might choke a graphical browser, there's Lynx.
Most of the plugins (not browser add-ons, but actual plugins) are switched off or set to Ask to Activate.

NoScript, Flashblock and Adblock Plus (ABP) are the must-have extensions for Firefox, without which normal web browsing would be impossible.

For many years, I didn't even use an adblocker, and entirely relied on NoScript and Flashblock, but video ads on YouTube had finally caused me to install ABP.
I recall this was gradual, and I used to use only Flashblock, but then having to use older Internet-connected computers (around 2010/2011 or even a couple years earlier), I finally resorted to using NoScript, too.
Since Firefox and SeaMonkey share the same rendering engine, these settings and add-ons apply to both.

On my currently-primary Firefox profile, I also keep the same session for many months, with lots of tabs that could instead be saved into bookmarks, but Firefox is set only to open the tabs that I select at startup.

The PlacesCleaner add-on can occasionally be used clean up the session database that's become a bit messy over all those months. In time, I'll transition to a new profile, so that I'd be able to do some work and stuff and keep the bookmarks. And it's likely, that with this Firefox profile, I won't be saving the session, and will use bookmarks instead for all the stuff I want to read later on.

Sunday, October 23, 2016

Galaxy Note 7 and possible causes of fires

When thinking about the possible reasons why Samsung Galaxy Note 7 became flammable, I asked myself several questions: Can a magnet affect a phone battery? Are there magnets in the S Pen — the stylus that comes with the phone and that stays inside the phone case when not in use? Were users with phones that burned, using leather holsters with magnets (as many people do with other phones do)?

As a disclaimer: This blogpost is pure speculation rife with theories and hypotheses unconfirmed by hard facts (scientific or otherwise), much of which is original research. Neither do I know very much about how smartphone screens are made, and my knowledge of chemistry and physics is lacking. Many of the claims are qualified with terms, such as "likely", "possible", "probable", and so on. The intention of the post is to ruminate over what caused the fires, since finding the cause would be in the best interests of Samsung, other smartphone makers, and the public at large. In addition, I'm a user of two Samsung phones, one of which is a smartphone.


I began looking for news articles about Samsung Galaxy Note 7 and magnets, and came across this one from August 22, 2016 published by Korea Joongang Daily:
"Samsung’s Galaxy Note 7 is marvel of waterproofing".

The article explains, that:
The Note 7 and its S-Pen can work under water, because the phone's LCD and the S-pen respond to one another through a magnetic field in much the same way pieces of iron move in the direction of a magnet, when said magnet and iron pieces are separated by paper.
Further:
Even with water between the display and the S-Pen, the device "recognizes and responds to the S-Pen’s magnetic field."

My conclusion is,

that the phone battery was susceptible to magnetism, because it wasn't sufficiently protected from magnetism inside the phone, where the S-Pen was housed. The additional reason could be, that the internal phone battery, apart from some plastic, seemed (according to teardown photos) to lack any other protective material to shield it from magnetism.

All this suggests, that the Note 7's LCD is a magnet, and the S-Pen is, too, and the battery in the phone is still about the same in terms of its own housing as used in earlier models.

This is based on the assumption, that the housing of this kind of internal battery has not changed much from earlier internal Galaxy Note and Galaxy S batteries. The fact, that batteries with similar housing didn't combust in earlier Galaxy models, was because magnets (or magnetism) were not used in the screen and the new S-Pen.

The possible design mistake in the Note 7 is, that the engineers probably forgot to account for the fact, that the battery, with its usual housing, was susceptible to magnetism that emanated from the phone's screen and the S-Pen, either during use or when idle.

Samsung won't refurbish the recalled devices, and won't reuse its components.

Whether the magnetic screen and the magnetic S-Pen are the reasons for fires in the batteries, is unknown. Whether Samsung is currently aware of these as the underlying issue(s), is also unknown. And if it is, the public should know when the company first realised this.

If I were a mobile phone manufacturer, and realised, that the magnetic screen and stylus were affecting the batteries, then as a matter of business, I would halt production of this model of device, and choose not to refurbish or reuse the magnetic screen and pen that would adversely affect any normal battery that's close by.

The most widespread photos of exploded Note 7 models show, that it was the screens that burned through the most, but not the backsides of the poor phones. Investigating the burned phones for the direction of the burns and fires should confirm this. Granted, the backsides of the phones were made of metal and other materials that were stronger than the screens, and explosions and fires would move towards the area that would first give way.

Another interesting thing that the photos of burned Note 7 phones show, is that the screens burned through completely at the location of the batteries. Part of this burn-through could be attributed to extreme heat from the burning batteries, but I'd imagine, that the displays, made of mostly glass, would stay intact.

I do not know, whether it was the S-Pen, or the screen, or both that were ultimately culpable for affecting the batteries.

No issues were probably found in testing, because the effect of the magnets was not immediate.

I can imagine, that both the phone and the S-Pen were developed by separate teams, and I think it inconceivable, that the S-Pen was never inside the phone during testing, or that they were not tested in conjunction.

The U.S. Consumer Product Safety Commission would be very smart to subpoena the carriers and Samsung for lots of Note 7 devices (not just tens, but more) to find out independently what went wrong.

In addition, The Times of Malta reported, that "a team scientists at New York University led by Alexej Jerschow, developed a magnetic resonance imaging (MRI) technique to see inside the batteries as they are charging."

This new method could be used at the behest of the U.S. Consumer Product Safety Commission to investigate the extant Galaxy Note 7 devices—both original ones, and replacements. Care should be taken with the fact, that the screen and the S-Pen of Galaxy Note 7 phones are themselves magnetic.