fensgrim

good luck finding a phone with custom ROM support, when there will be no phones with bootloader unlock available :(

IMO it comes down to marketing: can't have the kayfabe of selling something that is "not a computer"/"new kind of computer" and have it act like a "computer" too

Looks like Chemical Garden trilogy by Lauren DeStefano might be a fit - but as it seems to be a cross between typical young adult fiction of 2010's and poorly made romance novel, I do hope there's something less.. pulpy.. with the same premise.

Also, isn't it really stupid to treat the wind the same way we do with rivers or with electrical current (which is actually flowing the opposite way to electrons, so not like the river/wind at all)?

E.g. country A is saying that country B is stealing their incoming (upstream) wind, but there's currently a zone of negative pressure (based on the mountains/shore/passing by cyclone/whatever) on the country A's territory which actually allows for the pressure gradient to form through both countries A and B - so there's more energy potential available to tap into on country A's territory?

There's Incredibuild (paid), might be worth investigating if it fits your scenario (I have serious doubts it'll work with anything other than basic AOSP due to how lineage's ninja behaves during its early build phase of regenerating scripts from .mk/bp's).

Mind if I ask what's your current record on build time for single device/buildtype combination's systemimage on a single node?

Looks like its easy to wipe and flash the bios chip by CH341A plus a couple diodes to get voltage down to 1.8V, likely without desoldering it too; yet finding the bios image seems to be somewhat impossible due to byte rot (adding extra steps to dump the image with the CH341A, locate the start of data blocks, wipe them).

> just like Arch Linux

and even Arch (Artix) can't be stripped of elogind and such

Neither, it's unethical and there's no possibility of doing that in legal way.

However I do write 1-2 hour PoCs on my spare time and my own equipment, using only publicly available stuff - they sometimes come handy at some point later. If we assume 'remote first' development is okay - with no possibility to test stuff locally, well, we're back to either bookmark managers or pet projects to keep at least a bit of knowledge between jobs.

> how a developer manages assets like source code

IMO there are some workloads, where it is beneficial for a developer to have access to a local repository with at least some snippets based on previous projects.

Having a leftover PoC of some concept written for a previous employer but never elevated to team use/production is both handy (at least to confirm that the build environment is still viable after an unspecified period of toolchain updates) and ethical (copying production code is not ethical - even if the old and new products are vastly different e.g. last job was taxi app, new app is banking app).

Making it all 'remote' and 'cloud' will eventually result in a bike reinvention penalty on each new employment - not everything can be rebuilt from memory only, especially things that are done 1-2 times a year; sure there is open-source documentation/examples, but at some point it'll just introduce even heavier penalty for a need to either know a lot of opensource stuff to have some reference points, or to work on a pet projects to get the same amount of references.

> special locally installed apps in enterprise ChromeOS environments

There was https://developer.chrome.com/docs/apps/overview though, so this seems to be a kind of planned feature creep after deprecating former one? "Yeah our enterprise partners now totally need this, you see, no reasoning needed"

And they will provide it as required per law. Note that the law does not require them to provide that in a form that would be usable for anything practical without doing moderate to heavy amount of reverse engineering (e.g. here's the source, here's the toolchain that was released in approximately same period of time, go figure out if this can even be built without recreating part of their internal build system, missing configs, etc).

Ooh substances - scary stuff. Must be very dangerous to allow selling a thing that could be made with any CNC router out of scrap, so let's also ban CNC routers.. eventually, let's ban hands as they can be used to do stuff. /s

Another reason is that giving users the option to root and unlock is possible only after ditching whatever agremeent is in place with Google. So, no Play support for this vendor at all means no sales to normal markets.

Going deeper in conspiracy theories, Google would drop Qualcomm/Mediatek from the ecosystem if they'll ever allow a single SoC licensee to do such phone.

Last decade's definition of "power user" is "being able to type on physical keyboard and have more than 1 window open at a time", and Android caters to that; it would not even remotely be decent, though it'll likely eat just a bit more battery and cpu than a pure XFCE running without compositing.

So far, we can't even get Samsung to have their FOSS kernel stuff published in a buildable and usable form - its basically impossible to build their recent kernels with their recent toolchains without finding out that some obscure config option was skipped or that some file didn't survived the pre-release purge or that it requires some obscure Linux distribution to run on. And if you get it to build, chances that it will boot are slim. (Good luck finding out if there's a working UART somewhere on chip pins and it's not hidden behind hypervisor and fuses)

There's likely a statement in Play Services ToS for vendors to do all things possible to prevent bootloader unlock/relock flow from happening - reasoning from the fact that yellow AVB state is non-existent outside Pixel devices. Maybe it goes as far as for SoC vendors, as well. So far, outside of Huawei, no top tier hardware vendor ever decided that denying Play functionality to their users would be profitable - also all Mediatek based devices are basically licensed by mediatek afair, so there's no chance of, say, Vivo/Realme suddenly deciding to ditch Play and do bootloader relocking.

Also the possibility of postmarket devices running non-bloated OS is a loss for a vendor since it both reduces the appeal of whatever next "+1% cpu +1% battery" lineup update (and its a bad idea to sell 200k "good device model 1" rather than 100k "bad device model 1" and "bad device model 2", because PR/stocks/whatever) and increases the possibility of having users dissatisfied with the brand name because battery/flash degradation is still a thing.

I'd go for a "real device cloud", AWS/testgrid/browserstack/whatever.

However depending on your users' demographics, it might be a good idea to take a look at https://dontkillmyapp.com/ and get few used devices from huawei/xiaomi to run local tests as well, generally the farm experience wouldn't exactly match local experience (e.g. what happens when you leave the device without usb connection running overnight, what happens when you leave device unattended for a week). US/Europe? Don't bother. EMEA? Maybe get a couple devices running lineageos/grapheneos/calyx as well. China? There's https://www.alibabacloud.com/help/en/mobile-testing but it wouldn't match real user experience due to how dpi/GFW is set up.

Also check out https://developer.samsung.com/remote-test-lab and https://developer.huawei.com/consumer/en/digix-lab/ if you want to save some bucks on renting stuff.

It is possible to have a project set up with a manifest which contains only a single activity with android.app.NativeActivity pointing to a .so, and zero lines of java/kotlin/flutter/whatever else - though your app initialization will go through usual hoops of spawning a java-based instance.

Minimal example would be https://github.com/android/ndk-samples/blob/master/native-ac..., though there are well established Qt based apps as well

@dang I think this one was supposed to be https://www.reddit.com/r/pcmasterrace/comments/1ax1dn7/lost_...

On topic of this specific kind of vampire, see also: Blindsight, https://en.wikipedia.org/wiki/Blindsight_(Watts_novel)

After OPPO/OnePlus merger, things went downhill really fast. IIRC, OPPO did something that ended up alienating some parts of Lineage/ROM developer community in general and the work on supporting newer devices was postponed until couple months ago; also, they've patched up the bootloader relock possibility [0] which was likely good for security considering it was based on some exploit.

0. https://calyxos.org/news/2022/07/06/oneplus-android-12-reloc...

> Xiaomi

mtkclient [0] would let you skip the whole 7/14 days thing (also: unrestricted partition dumping/flashing). Though there are chances of ending up with soft/hard brick (normally possible to revert back to working state as long as you have backups), and there may be no support for your specific chipset/device/software revision at all.

0. https://github.com/bkerler/mtkclient

Unless your phone has fastboot already unlocked, yes it will result in you losing all the stuff at least once (there's an unavoidable wipe on bootloader unlock/relock). In that case, if your changes are restricted to surfaceflinger rather than kernel code, you can try doing an emulator-based test (basically, just do 'm' and 'emulator' commands your from AOSP build environment).

Also, when building kernels for your specific target (4a), pure AOSP is actually least friendly option regarding build scripts/instructions; consider either building the kernel as a part of either LineageOS build (which will pull MSM 4.14 kernel) or CalyxOS/Graphene (which has its own kernel build scripts/sandbox).

That specific blindness story was debunked later on (~month past initial report); something about having only a single unnamed source touting that story to multiple newspapers.

As a russian rave goer: my deepest thanks to aliexpress providing lots of reliable UV LED sources, X-Y lasers etc. It really keeps the (insane) DIY at bay.

> they were popular during covid

They were popular long before covid: https://de.wikipedia.org/wiki/Quarzlampe

TL;DR: invented in Germany, 1906; introduced as a nationwide cure for rickets in German children in 1920; adopted by soviet medicide nationwide in 1950s and never really went away

As for covid, it did trigger a number of insane DIY projects involving UV light sources; I like this one in particular - https://youtu.be/nFSkBsKAH-A?si=SLgdtdvLcNN-sTs0&t=187 (yep, that's a 125W streetlight mercury vapor lamp being stripped down into a hard UV hazard.. These go as far as 1000W, though 125W variation is most common and easily obtainable, at cost of $5 per lamp, and ~$30 on spare parts to get it up and running)

> provide support when the customer has trouble understanding how to connect to a device on their local network.

Is it possible to order current revision of TinyPilot for someone in a remote location and connect to it on arrival through some managed service - without going through all the hoops of helping end user with setting up some form of reverse shell (e.g. either meshcentral or openvpn/wireguard for webinterface)?

I had plans to do such project for exactly same reasons since, like, 2011..

Wanted to have pulseaudio/alsa dmix handling multiple streams/mixing them out with a help of dedicated hardware BT/DAC-ADC-BT path, with a goal to have smart handling of voice calls over music on the go, fake 5.1 in the room, and a voice enhancer / fast rewind for call streams..

Then, Volumio took enough of the raspberry-based hifi market (despite having no bluetooth support, lol) that I've declared these plans no-go as investing in this solely for fun wasn't that enticing, compared to just getting a spare set of equipment to separate work/home audio.

my 2¢: if external storage is not an option for some reason, dropping ext4 in favor for F2FS will do a lot of good for sparing your sdcard from early death (due to superblock updates happening every so often), if not for performance due to ext4 not being flash-aware by design.

If that's not an option AND your setup has no power issues (e.g. it has good power supply, externally powered usb hub etc), disabling journalling might also improve performance: tune2fs -O ^has_journal /dev/sdaXXX (can't do it on mounted fs, so either do it from initram consolee, do pivot_root to minimal fs in ram, or do it from another machine)

> The more layers the attacker has to break and the harder each layer is, the better.

No its not, when it comes to end-user app performance, experience or privacy.

Sure, by adding security we can have another reason to let developers end up with golang app compiled to wasm running within electron sandboxed through API redirection (OS + antimalware/antivirus/BPF based EDR) and use it for, like, listening music in a very secure way..

With all these layers happily streaming all kinds of telemetry to knows where, with owning nothing but a bunch of numbers behind a ton of DRM layers, and with no ability to change things to the point where we can't have an app's theme matching system colors because crossplatform compatibility/security reasons.

Case 1, firefox:

> dom.security.unexpected_system_load_telemetry_enabled > security.app_menu.recordEventTelemetry > security.protectionspopup.recordEventTelemetry > security.certerrors.recordEventTelemetry

I don't want to accept developer's assumption that these have to be enabled by default.

Case 2, Windows: can't even do a build of a trusted codebase under IntelliJ without antimalware adding up, like, +150% to build time. While IntelliJ (or some of its extensions or plugins that creep up during development) is happily reporting that performance issue back to its masters. Ugly.

With GrapheneOS targeting whatever Pixel as their only primary device (not going to go into whole GSI/DSU thing), there's a "lucky" coincidence of TWRP for all Pixel devices I had (3 to 7a) being broken (keymaster, userdata).

So, if you wanted to add GApps to pre-"Apps" Graphene, it involved either repacking system image, or building your own copy of OS with OpenGApps (had to do it once to get specific e-sim app working iirc). Can confirm that either way was fine, so it was possible to get GApps on Graphene back in 2021, nobody bothered with it though.. what happens next: someone decides that they want to make it nicer for users and goes there by making yet another appstore.

With CalyxOS, its possible to do the same thing: - get the sources - remove microg packages (pity. They really do maintain and test their own fork, meaning less login issues, etc) - add OpenGApps (or Revanced's MicroG) - run the build, wait 2 hours, flash it

Now.. there's no such thing as "GApps compatibility layer" in Calyx. Yet, there's no difference in user experience - none of my daily apps are/were broken on either Graphene+Play services from their store, stock CalyxOS+MicroG or on Calyx+GApps. (Except last time I've used Apps on multiple user profiles, there was a lot of trouble due to different versions being installed iirc)

Taking privacy concerns into account, there might be some difference.. but once more, going through gmscompat code, I see mainly hacks about letting this app pop up this activity this time, faking this permission that time, etc [1].

Yes there's a layer that isolates some calls, but I just cannot see how it's supposed to alter user experience. Now, spinning an isolated "sandbox" (which is likely impossible, as IPC/binder/shared data and services model is fundamentally broken anyway) with just a couple apps on a separate google account - all restricted from having access to sensors, etc, having device ID's spoofed and having separate network isolation - would be a real game changer, but its a niche need, with semi-available solutions (sandvxposed, vmos, waydroid on docker on android), and it would likely violate every line in Play Services' TOS meaning it won't happen on a public OS.

Calyx cares about their users in a kind of a quiet way, yet there's a ton of activity on their tracker.

GrapheneOS cares about giving privacy to more users I suppose, so that explains their marketing strategy and parts of their code being what they are (hardened libc? definitely cool. Yet I've not seen any public exploit that could bypass e.g. stock AOSP's libc with _FORTIFY_SOURCE since 2015).

End user experience though? No real difference, thus no superiority. And people in need of "hard" sandboxing would just buy a box of burner phones anyway.

1. https://github.com/GrapheneOS/platform_frameworks_base/commi...

P.S. What about that SafetyNet certification on either OS?

my 2¢: Russian could be assumed as a minority language for all* of ex-USSR countries, so OP missed Armenia/Georgia/Moldova.

Also, it would be interesting to see partial overlap cases (e.g. Ukrainian-Belarussian, Russian-Serbian) where one party could understand another but couldn't answer well except in "universal" sign language (or through switching to another common denominator language); though good luck with researching this one.