537 karma · joined June 24, 2020
Agree, but I would say it differently : users ought to be able to push their own keys while keeping the "secure boot" feature. e.g. "fastboot key push <key>"...
> An open standard API for device drivers should be mandated
You would also need to convince kernel devs to reconsider the "stable api nonsense" ideology... (https://www.kernel.org/doc/html/latest/process/stable-api-no...)
No, but most people also don't need SoCs which performance doubles every 2 years. If the software was properly written and optimised (which would be more common if the firmware developers expected the hardware to have a long lifespan), there would be no reason any phone manufactured in the last 7 years to be sluggish. Anyway most people just want their basic apps to work (e.g. phone, emails, whatsapp, agenda, hotel booking, photos, maps, chat, music player, etc.), none of which should require a very powerful CPU or tons of RAM...
First, let's remind that LineageOS does not run on 15 year old smartphones (and they drop support for a device when there is no upstream support from vendors on the same Android version).
One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all" i.e. you need some custom adjustments on your kernel for your SoC and board. Since a few years we have device-tree which improves a lot the situation, but I understand it does not cover everything (i.e. there would still be some missing aspects compared to UEFI/ACPI with regards to hardware description. Maybe some embedded experts can comment ?). Besides it is still not always implemented in chipset vendor's BSP which sometimes still rely on board files (where the data is not easy to extract from a binary kernel, noting that a lot of low-end OEMs do not properly comply with GPL and do not publish their sources)...
* being able to detect not only duplicate files but also duplicate dirs (without returning all their sub-contents as duplicates)
* being able to query multiple times without having to re-scan, and to do other types of queries (i.e. I am computing a hash on all files, not only of those with duplicate sizes. This makes scanning slower but enables other use-cases. N.b. beware that I only hash fixed portions of files for files>3MB, which is enough for my use-case considering that I always triple-check the results and is a reasonable tradeoff for performance, but it might not be OK for everyone !)
* being able to tell whether all files in dir1/ are included in dir2/ (regardless of file/dir structure)
* being able to mount the sqlite index as a FUSE FS (which is convenient for e.g. diff -r or qdirstat...)
Still work-in-progress, yet it works for several of my use-cases
"1) A truly open format is available" : sqlite is open-source, MIT-licensed, and well specified (even though I am usually not so happy with its weak typing approach, yet in this case this precisely enables a 100% correspondance between CSV and sqlite since CSV has also no typing at all...)
"2) Applications have a speed increase from using csvs" : I think it should be obvious to everyone that this is the case...
"3) The new format should not be grossly larger than the one it is replacing" : this is also the case
For example, one pretty nice cross-platform GPU-enabled stack :
https://github.com/bkaradzic/bgfx
On pure computing power, yes of course. But - at which price compared to A1200 ? (of course in the case of the PC you have to include a reasonable sound card + reasonable graphic card. I could buy my Amiga as a teenager in 1993 for less than 500 € while any entry-level Pentimum MMX PC in 1999 would still be > 1000 €...) - The OS was fantastic, very responsive despite the limitations of the hardware. Only when I left Amiga to switch to a supposedly much more powerful PC I experienced what meant "lagging" and "bloat"... (original Amigas didn't have an MMU and therefore both OS and apps were written carefully since there was no swap)
It is indeed an innovative way to give access to spectrum, but it's a pity it has been done in this band (which had a huge potential for usual operators in terms of site reuse).
I suspect in Europe a light licensing approach such as CBRS might be considered in higher bands such as 26 GHz...
However, those provisions are made in order to ensure a good/fair access to anyone, and therefore to prevent a single user or single technology from overusing those bands which are meant to be shared. For that purpose, there are associated restrictions (in terms of power/EIRP, duty-cycle) and/or mandatory sharing approaches (Listen-before-talk, detect-and-avoid, etc.). In the case of Wi-Fi, CSMA/CA is a form of listen-before-talk.
Unfortunately, mobile technologies defined at 3GPP (GSM, HSPA, LTE, NR) are not designed to be used in such a way (i.e. they don't have any sharing mechanism such as LBT and they require _by design_ dedicated/licensed bands), which by the way implies some kind of specific coordination at the country borders where two operators are using the same channels... (you might look at ECC recommendation 15-01 for an example of PCI sharing).
LAA is a way to have an LTE carrier within the (shared) 5 GHz band, but it has to rely on an anchor carrier for signaling, which requires licensed spectrum. Multefire is a fully-unlicensed solution, but I doubt many UEs (smartphones) support it, and anyway because it must implement the same power limitations and LBT as wi-fi in order to comply with regulations I doubt it would be much better than wi-fi... (maybe it would in some specific case where deterministic QoS is important)
One more thing : keep in mind that a typical 3G/4G/5G macrocell site (e.g. around 65 dBm EIRP per carrier) is something very expensive : your mileage may vary but it can easily be around 100000 € / site when some construction is required.
Last but not least : I should mention that this researcher J.M. Friedt has an amazing amount of wonderful material about clocks, oscillators, SDR and so on... http://jmfriedt.free.fr And more specifically on DCF77, I could find http://jmfriedt.free.fr/dcf77.pdf and http://jmfriedt.free.fr/dcf77.mp4 (among other things)
Maybe, but PNaCl (unfortunately deprecated by Google) "defines a low-level stable portable intermediate representation (based on the IR used by the open-source LLVM compiler project) which is used as the wire format instead of x86 or ARM machine code" https://www.chromium.org/nativeclient/pnacl/introduction-to-...
However... "Low CPU and memory footprint (...) memory usage is under 20 MB for a Hello World program" : I am the only one who still thinks this is huge ? (-> https://tonsky.me/blog/disenchantment )
1°/ individual intelligence and technological innovation is not necessary an ultimate achivement that enables competitive advantage : human beings may be individually smart (compared to some other species) yet the collective intelligence of humanity is rather poor (which translates to the unability to solve collective problems such as sustainable management of our finite natural resources (e.g. oil) or of the consequences of our activity (e.g. biodiversity fall and climate change)). I suspect humanity will experience in a few decades a major regression (if not extinction) which could be interpreted as natural selection because of lack of collective intelligence. The same could also happen to other civilizations and maybe technological innovation the way we see it today is not necessary a ultimate achievement !
2°/ even if some other intelligent species would exist, maybe they would not have the same need to communicate, the same need or will to travel, the same need or will to innovate, etc.
3°/ even if some civilizations could be infinitely smart both individually and collectively and have enough genius to implement all engineering allowed by the laws of physics and have the will to implement it, maybe the laws of physics together with the nature/amount of natural resources on a typical planet do not enable such intergalactic space travels ! Sure, we were able to fly to the moon and we can make 5nm transistors while our ancestors would never have believed it could be done and it might make us dream that "everything is possible because genius and engineering have no limits", yet I would still be careful and such claims sounds more like religious faith than science. People need to understand the enormous distances we are talking about here and we need to remain humble that maybe it is and will remain forever an obstacle :)
Here (as far as I understand) the main issue is the airborne receiver blocking (i.e. catching energy from other bands) because of poor filtering on the receiver side.
1°/ transmitter unwanted emissions of 5G (i.e. how much out-of-band/spurious emissions "leak" outside of the 5G band i.e. above 3.8 GHz). This is most likely a negligible issue here even though there are still uncertainties whether the antenna pattern of AAS remains the same in-band and in spurious emissions
2°/ receiver blocking of the radio-altimeter (i.e. even if 5G emissions were perfect, the victim receiver can catch energy from other bands if it doesn't include a proper filter) : this is most likely the main issue here -> from my understanding, those airborne equipments have poor filters (the antenna limited passband probably helps a little bit which is why this blocking phenomenon did not happen previously with 4G in lower bands, but apart from that there is probably a low selectivity with regards to adjacent bands)
It's not only about POSIX. After the X years of planned lifetime (with proper software/OS updates), will there be any solution to extend the lifetime (which is what I used Linux for, on > 10 years-old laptops) ? I guess there will be no solution against planned obsolescence...
And with regards to control and privacy : will Apple finally give-up their policy of deciding (and tracking) "for your own good" which apps you are allowed to install and launch ?
As far as I know 3GPP2 cdma2000/EV-DO also need GPS because the codes are synchronous (although I am not familiar with those technologies).
Apart from that, 3GPP FDD base stations only require a stable frequency reference, not a time reference (LTE/WCDMA base stations are not connected to GPS !)
My understanding is that this is what Google's PNaCl was about (https://developer.chrome.com/native-client/nacl-and-pnacl) : leveraging LLVM bitcode for both portability (source and target) and native performance, being able to sandbox properly the resulting executable.