karteum

Unless there is a major disruption, in 50 years we will have hit hard the limits of earth natural resources (in terms of metals/minerals/oil) and the consequences of climate change so it's very difficult to predict how the world will be. My guess is that once the system reaches some kind of new equilibrium, jobs will be mostly low-tech and very similar to 1 century ago : farmers (with permaculture), bakers, people who repair stuffs, blacksmiths (but with far less volume of production compared to the industrial world we live in today and mostly simple/repairable/low-techs stuffs : hammers, bikes, shovels, plows...).

> Alternativer take: vendors should get their drivers upstreamed so they don't have to maintain them much

This is ideology. In real-life, some OEMs are binded by NDAs (so they can't do all what they'd like), and the split between hardware and software is quite blurry (chipset vendors don't want to disclose their secrets by open-sourcing their code).

I wish like you that more code would be supported in mainline kernel (just as I wish every single board would support SystemReady/UEFI or any similar solution (ideally more lightweight) so that they could boot a generic kernel just like x86 does (and regardless of the availability of the proper dts for this specific board, which may be hard to download after several years)). But this is not the world we live in.

Because of this "stable-api-nonsense" ideology, we end up with piles of junk (e.g. all old smartphones and boards that become unsupported after 2-3 years... and we only have one planet !) while we can still easily use 10-15 years-old PCs.

Is it a Google issue or a Qualcomm issue ? (e.g. does it occur when using Calyxos/GrapheneOS/LineageOS instead of the raw Google Android OS ?)

I doubt my Oneplus 5T has UEFI (and I can see for sure that LineageOS still releases device-specific firmwares rather than generic ones...)

> The problem with long term support for my Android phones has actually not been the fact that Android devices have incredibly short security update windows. That issue has been somewhat mitigated with the newer Google Pixel phones which have five years of security updates

5 years of updates is still a short time. We only have one planet...

> The biggest issue for long term cell phone support is, even if we get an OS with a 10-year security update timeline like Rocky Linux, will the phone itself be able to make calls on whatever cellular networks exist 10 years from now?

I don't think this is the biggest issue : operators usually maintain a certain type of carrier for at least 20-30 years (in France, we are only talking about shutting down 2G - which still raises a lot of issue because of the many IoT devices using GSM...)

The biggest issues are IMO

  - lack of parts to repair old phones
  - no possibility to manage bootloader keys / relock the bootloader (not even mentioning devices with locked bootloaders)
  - "stable-api-nonsense" ideology and no BIOS/UEFI/ACPI for smartphone => no way to have "one firmware to rule them all"

Thanks for this !

Just to better understand some of your technical choices : are you using microG ? Do your phones pass SafetyNet ? (there are many apps that do not work out-of-the-box with custom roms, e.g. bank/payment applications, etc). !

May I also ask : why did you create your own rom rather than contributing to existing projects with a similar target ? (e.g. /e/, calyxos, grapheneos, which start from LineageOS and add some extra work to mimic or sandbox Google Service Framework and precisely care about privacy...)

Good initiative. But (for a topic I know) I can see it's highly incomplete with regards to the telecom sites. In France, we have this site https://www.cartoradio.fr/#/cartographie/stations made for that purpose (and which is made by the administration that takes care of radio site registration). There is also this one for microwave links https://carte-fh.lafibre.info

So the typical Tesla driver has an above-than-average income ? Thanks, captain obvious :)

Doesn't https://www.overleaf.com offer almost instant preview ?

The issue has been known and adressed in France for a while (and to my knowledge, France has been pioneer in handling the topic seriously. e.g. see https://www.anfr.fr/liste-actualites/actualite/la-protection... ).

5G base stations have compliant out-of-band emissions so the issue is not "because of 5G" but rather "because radio-altimeters gather energy from adjacent bands" (something we call "blocking"). Not all radio-altimeters are the same, but for some of them there is very little filtering and the only thing that protected them from good old 4G was that the antenna behaves somewhat as a filter and 2.6 GHz was far enough from 4.2 GHz... It may sound silly for a safety-critical equipment, but we really have to think about the really long lifetime of those equipments and think with the context of the time when they were designed/deployed (e.g. if there is only space-to-earth transmission in adjacent bands, why would they put filters that would add insertion loss and cost ? In the 80's there was no 4G/5G in sight...). Probably the aeronautical authorities also failed to inform the relevant issue in due time within the spectrum regulation process, so this has not been known or studied properly at ITU/CEPT/etc in the context of those frequency bands close to 4.2 GHz. It also seems that the radio-altimeters vendors keep a lot of secrecy on the technical details of their equipments (a part of the internal culture which also comes from the dual civil/military use of those systems) so even people who represent civil aviation authorities or aircraft manufacturers such as boeing/airbus in spectrum regulation authorities do not always have full access to the relevant information.

Now the situation is what it is, and the short-term solution is to have some kind of 5G exclusion zones around airports, and of course operators are not happy with this because they paid huge prices for 5G licences and now they discover that they have new/additional constraints around airports... Long-term solution is also an issue, because it is not that simple to put filters on existing equipments (if they change the behavior, the whole computer need to be re-calibrated, and pilots trained, and the whole thing re-certified, which is also not as simple of doing it once and certifying all aircrafts from the same model but really must be done one-by-one in a custom way for every aircraft). I understood that new specs for radio-altimeters will soon be out so we can hope that the situation improves soon as the retrofit will be able to start (even though it will take years), but there is a possibility that even new radio-altimeters may still continue to be vulnerable to blocking in 4-4.2 GHz in order to maintain their required accuracy (I'm no expert in radars but I trust those people who told me). So the issue will be solved with regards to 5G in 3.4-3.8 GHz as deployed in Europe, but maybe not above 4 GHz (which is one reason why it may be better to restrict to low-power/verticals in the future uses in those bands).

Anyway, this is a complex topic as you see...

> What's with the hacker community and their obsession with a terminal emulator?

Because unlike web apps, terminal apps are often fast (and even faster when the terminal has HW acceleration, see for example https://alacritty.org). Unlike native GUIs, they can easily go through a low-bandwidth network connection (e.g. ssh). They are often portable and can be easily made stable without a huge stack of dependencies.

Actually my point was not to emphasize on this tragedy, but rather to highlight that the "solution" (to use helium instead of hydrogen) would probably only work at low scale considering how limited helium exist on earth...

If we want to scale airships (which I would be delighted to see), then I guess we have to go back to hydrogen, and then I would like to see how they would proceed to ensure safety.

If it's filled with helium, I guess it won't scale to replace the thousands of aircrafts in operation due to the finite amount of helium on earth. If it's filled with hydrogen, then people should remember the Hindenburg tragedy (and R101 too, glorified in Iron Maiden's "Empire of the clouds")...

For simple matrix-like effects, I use

  <canvas id="matrix" style="display:block; position: fixed; top: 0; left: 0; z-index: -100;"></canvas>
  <script type="text/javascript">
  var matrix = document.getElementById("matrix");
  var matrix_ctx = matrix.getContext("2d");
  var mletters = "01"
  var font_size = 10;
  matrix_ctx.font = font_size + "px arial";
  matrix.height = window.innerHeight;
  matrix.width = window.innerWidth;
  var columns = Math.floor(matrix.width/font_size);
  var lines = matrix.height/font_size;
  var drops_reinit_threshold = 0.975; // lower value means more frequent reinit and therefore more drops
  var drops_y = Array(columns).fill(1);
  function draw()
  {
    matrix_ctx.fillStyle = "rgba(10, 10, 10, 0.04)"
    matrix_ctx.fillRect(0, 0, matrix.width, matrix.height);
    matrix_ctx.fillStyle = "#050"; // green text
    for(var i = 0; i<columns; i++)
    {
      var letter = mletters[Math.floor(Math.random()*mletters.length)];
      if (drops_y[i]*font_size <= matrix.height)
        matrix_ctx.fillText(letter, i*font_size, drops_y[i]*font_size);
      else if(Math.random() > drops_reinit_threshold)
        drops_y[i] = 0;
      drops_y[i]++;
    }
  }
  for(var x = 0; x < 2*lines; x++) draw();
  setInterval(draw, 35);
  </script>

if the lines are strictly identical, you may just use

  cat foo.csv | sort | uniq

I think it is hard to ensure simultaneously the integrity/consistency and confidentiality of the electronic vote. "low-tech" paper ballots are easy to understand (including for elder/non-tech people), and make it more difficult to implement a massive fraud at scale. (Yet on the other hand, I admit that electronic vote makes it easier to implement more sophisticated voting systems, such as Condorcet (https://en.wikipedia.org/wiki/Condorcet_method) or Cardinal voting (https://en.wikipedia.org/wiki/Cardinal_voting)).

Notice that on the other hand it would be comparatively easier to make an electronic registration system ("X has voted", which does not require the same confidentiality), which then could enable people to vote from any voting office within their country rather than having to go to the specific voting office they are registered to.

And we could make it rely on Postscript and call it "NeWS" :) https://en.wikipedia.org/wiki/NeWS

A 10 (or even 15) years old machine is still perfectly capable, and we only have one planet so it's better to extend their lifetime when they still work.

I guess that the main benefit is not the saved 32kbytes, but rather the CPU cycles that are saved by not using jquery...

"jQuery is probably the least of their problems" : they also explicitly said that removing it was a low-priority background task, yet I like that mindset where they care about people having low-bandwidth or low-end devices "removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance"

Having a quick look : I understand they only listen and never transmit, and just decode MIB and SIB1 => why do they require a sophisticated and expensive SDR such as bladerf ? I though an rtl-sdr would be able to decode MIB (and probably SIB, but I have a doubt there because maybe the location of those resource blocks would exceed the rtl-sdr's limited bandwidth... I would need to check, but anyway it seems https://github.com/JiaoXianjun/LTE-Cell-Scanner is able to decode SIB)

"DwarFS compression is an order of magnitude better than SquashFS compression, it's 6 times faster" : I suspect this is on a highly specific test-case and no generalities can be made...

N.B. there is also EroFS https://www.kernel.org/doc/html/latest/filesystems/erofs.htm...

Me too : I wrote a few lines of Python for my personal use, to remove docx write protection, and a few other useful stuffs e.g. changing author names, shrinking the size of the document by converting .png/.emf to .jpg, etc. The function for removing the write protection is very short :)

  xmldata = ZipFile(docxfile).open("word/settings.xml").read().decode()
  xmldata = re.sub("<w:documentProtection .\*/>", "", xmldata)

=> I wrote it for my personal use and for a few friends, and it is unfinished and not very well written, but if it can be useful to others, my little tool is here https://github.com/karteum/Doctool

But git (and more generally diff) is not very efficient for detecting and showing moved text (which it displays as deletion+addition)

> "It doesn't surprise me that a massive, powerful, super-conducting electromagnet is capable of doing this. What surprises me is that it is only effecting Apple products"

May I suggest an hypothesis (I would be happy to hear from other people whether this might make sense. I didn't see this possibility mentioned by anyone on the Reddit page) : of course Apple is very secretive about their implementation details, yet as far as I know they are the only consumer brand who implemented Ultra Wide Band at large scale (in a quite innovative way, they can be praised for that !). See https://developer.apple.com/nearby-interaction/

I suspect that UWB implies having an RF receiver and antenna which are "wide open" in terms of frequency selectivity, which means that in the event of a strong RF pulse in the spurious domain, more energy might enter in the device compared to other brands. Maybe that's an explanation why Apple devices (and only those) were burned by an EMP ?

Yes, but if it was with a toggle switch (and a default value on "off"), then the user could decide and take the risk (and/or only activate it when needed), which would alleviate the risk.

I have a Oneplus 5T (dumpling) and get much less frequent updates (which puzzles me : I though they would have an automated build system i.e. that all supported devices would have exactly the same updates at the same time...)

I wish that LineageOS could accept the "signature spoofing" patch that is needed for microg (possibly with a toggle switch that would be "off" by default), so that we could avoid the need for the less-frequently-updated https://lineage.microg.org/ and properly install apps from Play Store without the Google Service Framework (that essentially give root access to Google on your smartphone).

(and actually I also wish they could implement the shims developed by https://grapheneos.org/usage#sandboxed-google-play in order to sandbox the google play services, so that the user could choose between approach 1 (microg with signature spoofing) and approach 2 (sandboxed GSF) on any smartphone supported by LineageOS (grapheneos only supports Pixel phones due to their ability to relock the bootloader))

Are there no longer issues with regards to the limited number of writes on flash chips before they wear out ?

For people interested in regulation in EU/CEPT area, unlicensed bands (ISM and SRD) are captured in ERC 70-03, where you can see the bands and associated limitations (in terms of EIRP, Duty-Cyle, and other things) https://docdb.cept.org/download/25c41779-cd6e/Rec7003e.pdf

Annex 1 is about generic SRD. The other annexes are about other bands and/or more favourable conditions for specific applications. This may seem complex and over-regulated, but there is a good reason for that :

- CEPT cares that all applications get a fair chance to access the spectrum (not just "the technology which emits the strongest signal") : for example, all Wi-SUN equipments (APs, relays and end nodes) can emit up to 500 mW (with power-control) while Lora end nodes have a 25 mW transmit power. Technical studies and simulations have shown that Lora (and siblings) would not survive if wi-sun was going to be widely deployed, and this is one reason why some parts of the bands for networked SRD have a 25 mW limitation while other parts are less constrained.

- those "additional opportunities" in other annexes are made based on dedicated technical studies (to check the impact on adjacent bands/services) that do a lot of assumptions with regards to potential/future densities of devices (because what matters if often the aggregated interference, not just the one from a single device)

I agree, but an an alternative to mbox/maildir format on your machine : I wrote https://github.com/karteum/gmvaultdb in order to have a single-file SQLite DB with all old email contents (all UTF-8 inside, simple/minimalistic schema), together with a small GUI to consult emails and do queries (full-text not fully implemented yet but this is the target) and all attachments extracted in a side folder so that I can directly browse with a file manager.