There was some "reference" upnp implementation (I don't remember where it came from, but it was used in real products) where you could do http://<hostname>/getfile/$(echo ../../etc/passwd |base64) ... and get /etc/passwd.
3,861 karma · joined February 24, 2017
But, the biggest Java user in term of number of devices is Android. And every time you install an app, you compile it. Including every time you update it (which nowadays is... everyday?). Also it'll recompile in background to use pgo. Nowadays [1] Google could pretty much compile it server-side for most devices, and save a lot of battery wear (batteries wear when getting hot, and compiling, weirdly, heats), in addition to power consumption.
I can't say much about US. As I see it, EU pretty much copied US about that part. There was nothing related to computation in the EU's AI Act projects until few months ago, it was purely a "what kind of data processing are you allowed to do?"
After some thoughts, in ReLU it does make sense, because half of the function is constant, so you can say that you're "cold" if that neuron's ReLU-ed output is often 0 . So I checked whether ReLU was common in LLMs, original llama doesn't use ReLU. But after (re-)reading the github, it actually only works on ReLU models. Turns out that there is a group of people "fine-tuning" (I would rather call that re-training, since you start by breaking the model?) models to use ReLU to allow for that sparsity: https://huggingface.co/SparseLLM
So this is sadly not applicable to any model you can find on the internet, but that sounds like a great progress anyway. Possibly this might shift the compromises back to bigger models but with "less ideal" activations. Also I'm curious what would be the legal impacts on it (since USA and EU refers to a model's FLOPs/number of parameters... How do you compute it with sparsity? Do you average?)
I think that a possible avenue for future research in that area is keeping original activation (like llama keeping SwiGLU), but using quantification to define "hot" and "cold" neurons to be saturation areas. (For example, saying that this activation function, below -1. at 8 bit, is equivalent to -infinity, and thus this is a cold neuron)
Connection is what is very complicated to do safely, but once its setup, except for some signaling, it is much simpler [1].
The architecture used by some people (I wouldn't know exactly who does what, it's all muddy) is that the connection/signaling is done in application processor, but the Encoding/Decoding + RTP is done in baseband processor. You do get a bit of additional of lag at connection (but anyway you have an UI to show), but you can keep your real time audio guarantees.
[1] That's for volte. For vowifi, that's more complicated, but anyway talking about lags over wifi...
For basebands yes. I'll complete this for a quick overview for IMS/VoLTE, which is often in baseband, but not always. (And VoLTE is at least partly what the article is about, and the last public Pixel remote flaw was caused by VoLTE)
Just to give a quick approximate overlook:
- If you're on a Verizon-branded device, Verizon probably made their own IMS implementation mandatory [1]
- If you're on a Samsung or LGE-branded device (no matter the SoC), they use their own IMS implementation [1]
- If you're using a non-Samsung-branded Samsung Silicon device (=SLSI: Pixels, Moto One Action and few others), they use a different IMS implementation than the IMS Samsung uses in their smartphones
- In other cases, you're indeed likely using the IMS/VoLTE implementation provided by the baseband/SoC vendor
As far as I know, the implementations I've marked with [1] are at least partially [2] done in userland in application processor rather than in modem, but it's hard understanding really. The ones that are not marked with [1] are in modem afaik.
[2] Partially meaning the annoying protocol stuff, but audio encoding/decoding + RTP encapsulation might remain in hardware
The article mentions parsing XML, doing DNS, IMS, TCP and IP stacks. As far as I know, all of those are down for one single purpose which is VoLTE (And VoWifi, and other related features which all go under the umbrella of "IMS"). On top of that, they also need to do IPSec (should be pretty safe) and SIP (gosh wait too much string handling). The remote Pixel security flaw few months ago was in that VoLTE stack.
This stack should NOT be in an embedded closed source un-auditable system. It should be in a "dumb" sandboxed opensource app in a sandboxed language.
This is exactly what I'm doing: https://github.com/phhusson/ims This is a FLOSS VoLTE + VoWifi[1] implementation for Android written in kotlin with no native code [2].
I'm not recommending it for anyone (I managed to make my first outgoing call with it yesterday), it has real issues (you do want baseband cooperation on various parts, like QoS or roaming to 3G, which I'm choosing to ignore), but I think software IMS is the way of the future.
In addition to security, this allows for a lot of de-obsoleting:
- It helps *a lot* for custom Android ROMs, and compatibility with annoying carriers
- I can integrate top-notch audio codecs (EVS) without breaking a sweat, and deployed for everyone in a jiffy (heck I don't even to reboot user's smartphone's to apply the change, I can just deploy it over Play Store)
- I can integrate modern voice improvements
- I can enable VoWifi on 3G smartphones (Granted, I'm not sure that's extremely useful)
- I can enable features that didn't exist when that smartphone model got released like Cross-Sim VoWifi (you have your french main SIM, you're in the US with a local eSIM, you can do VoWifi of the french SIM over the local eSIM to have cheap 4G voice calls)
I see some movement in AOSP source code that make me think Google will release an opensource IMS within two years, so I'm hopeful my work will be able to go to the trash.
[1] I'm kinda cheating for the wifi part, because it's provided by AOSP, I barely lifted the little finger to enable it. [2] Okay, I added rnnoise for the sake of having a denoising, but it's fixed-size-data-in fixed-size-data-out, so I feel safe there.
PS: I know that my knowledge of 3GPP is pretty thin, so if knowledgeable people want to tell me which parts will still need to remain in modem, I'm curious.
PS2: I'm putting this just in case: For GNU/Linux smartphones (or desktops with SIM card reader), you should be able to use that C+py stack to have userspace vowifi: https://github.com/phhusson/doubango
I think EU calling it "AI" is fine today. I'm more worried about the future. In 5 years when the hype word for this class of tools becomes Tchounka. The world will say that EU is late and they need to pass a Tchounka law. While the reality is that EU passed an automated data processing law and doesn't care about how it's done.
That's not what the EU regulation does. As an example, High Risk Machine Translation will be regulated no matter how you do it. The standard underlying the EU's AI Act explicit mention that AI system can be anything from rule-based to machine learning and mention some other AI methods. The regulation is on task/usage not on the technology.
Edit: "High Risk" in my example refers to the usage
That is too much I think? It would be weird to trust one notification provider for some stuff, and another one for others? Every user should be able to choose a "Notification Provider" is IMO enough.
On that front, there is already a push standard which is called WebPush which allows to do this seemlessly. Except it's only in browsers (also I don't think any major browser allows customizing it?). On non-Google Android, you have UnifiedPush. (It isn't a standard. Not sure it would make sense to make a standard of an Android API?)
I've been thinking of making a OwnerOS: a bare Android who lets users pick every component they want. You select which store you want, which assistant you want, which notification provider you want, which SystemUI you want etc. All of which currently require to root your device to customize.
I strongly recommend that product. As a STB manufacturer it is immensely useful. You can keep your 4k DV video output, and use a 10$ USB capture to develop and test as if you had a real TV.
It is also useful to reduce ewaste: there have been some 4k TVs without HDCP2. 2+HDMI 2.0, this makes it 4k again.
Likewise, I have an HDMI 1.4 AVR, this splitter allows me to use it at full feature (DTS-HD being not available in HDMI 1.4)
My only complain is not being able to switch to tunneled Dolby Vision (as a user you probably don't care), and it's not immensely stable (you probably want to give it a proper radiator)
Oh the other side, I miss the era of low volume content of passionate people. I didn't live such an era for the internet, but I did for smartphones. Back in 2009, you didn't need "have 25 people test your app" requirements, because people pushing apps cared about their apps. You didn't need to go through a dozen of apps before finding one with a usable amount of ads. Heck, runtime permissions weren't required because developers were reasonable in their usage of permissions
I'm not much a fan of videos, so I don't really know whether the same happened with youtube. But the way I consume the few youtube videos I watch is just to "follow" people [1], there is way too much meaningless content in youtube to even glimpse at what there is, and those algorithms really don't favor high-quality content, just baiting ones. So I feel the fediverse wouldn't have to grow much for me to replace YouTube.
[1] I also look at tournesol.app recommendations, but they are /waay/ too oriented towards their very own microcosm, and even though I'd like to contribute it takes quite a lot of time. That being said, I recommend taking a look at tournesol.app because there is real democracy research behind it
This explains that they are a duopoly, not a monopoly. However I do agree they are both a monopoly:
You're making a 10$ app targeting Californian 10-20 yos. They have 95% Apple devices (I don't know, I'm completely spitballing, but you get the idea.). You develop the Apple app, everything is going good, you have 1M users, Apple decides to cut you off on a whim (not saying they are doing it, but they are allowed to since they are legally not a monopoly). What does this "free competition between Apple and Android" is going to do to you? Re-target your game to SWE who are more likely to have Androids?
The Unity ruling seem to be clear to me that that the US law doesn't consider it a monopoly, and I acknowledge that. I can understand where this comes from. But it feels like laws need to be updated to take this new kind of situation (a local per-person monopoly impacting multiple distinct markets) into consideration.
I personally felt for it for quite some time: as a French we say our electricity is nuclear, so we're much much better than our eco-friendly neighbour Germany wrt carbon. But that's completely missing the point. (I'm not saying we're actually worse than them, but we all have still much to improve)
I fall in the area of people who think journalists' job is not just to report fact, but to properly phrase them to understand the implications, you might disagree with that.
I mean Youtube. Mentioning Youtube requirement is more relevant than Android's requirement since many more TVs and STBs ship with Youtube than just Android, and is older than Android's.
> If you're talking about LG, Samsung and Sony; yeah they have their own image processing hardware.
I'm not. Amlogic, Rockchip, Allwinner, Qualcomm, Broadcom, Mediatek, Unisoc, Google Tensor, Realtek. None of those SoC vendor use Mali for hardware video decoding.
Wikipedia [0] list a lot of SoCs using Mali GPU, but doesn't list a single one using Mali video decoder. Looks like they abandoned it since they haven't announced any new version since 2019.
Youtube made it mandatory to have AV1 decoding in TVs/STBs for new devices since 2? 3? years, so it should become more common. (but embedded SoCs not meant for TV are still way behind.)
> Mali being the biggest.
FWIW, on the vast majority of devices (well, all that I'm aware of), Mali isn't responsible for hardware video decoding.
And double its electrical power impact by going from hardware decoding to software decoding? I certainly hope not. (Anyway on TVs, it's impossible to do in software decoding, both because the CPUs are very bad, and even with literally 0 CPU you can't access 4K HDR surfaces)
> that HEVC will be replaced with AV1 in Netflix.
I personally would wait for AV1 to be court-tested before eagerly switching to it. Unlike dear ol' Theora, AV1 wasn't designed to not be patent encumbered. One would even argue the opposite. It is "patent free" only because Google claimed it was, and we're hoping noone will have the will to go against Google. Broadcom might have them.
> They rotated through three separate TV platforms between 2010 and 2015. The former of the two got shutdown ASAP after the transition.
> There is no sense of consistency other than their corporate schizophrenia with their products.
It's fun how I feel like you're quite literally describing Google/Android as well.
Google's TV platforms are Chromecast, Nexus Q and Android TV (and don't get me started on Google TV).
Android added widgets and then largely forgot about it. Nowadays looks like it came back (partly thanks to Apple supporting it?)
Android added blur in Android 2. Removed it in Android 3. Added it in Android 11. Removed it Android 12.
Android added dynamic backgrounds in Android 2. Then largely recommended to stop using it. Then added as a beautiful new feature in Pixels.
On a more purely technical note, I have even a better one: Does Android's boot.img contain an initramfs? In Android 6 yes, in Android 7/8 it depends, in Android 9 no, in Android 10 yes, in Android 14 no.
And Google also like to remove user's data without much recourse.