phh

I remember writing a blog with xml + xslt and thought it was very cool.

Retrospectively, writing code in XML, eewwww, but back then I liked writing XHTML by hand

I'm a custom ROM developer that spans a lot of devices (TrebleDroid GSI, a generic kind of custom ROM that works on thousands of Android devices) I've bought dozens of smartphones to implement bug fixes (current total number is 50).

I used to buy Xiaomi devices, because there are a lot of users (lots of bugs to fix), and often have brand new SoC at affordable price early. But I've stopped buying Xiaomi for a few years now, because of the low reliability, high complexity of Xiaomi's bootloader unlock, and the rules keep changing.

So far it looks like the community of people using Xiaomi devices with custom ROM is still pretty strong, so it's not necessarily a bad idea to buy Xiaomi. But I very strongly recommend that you unlock bootloader right after buying your device [1], because buying a device now and expecting to be able to unlock it in 4 years look too optimistic to me.

[1] Though you'll most likely won't be able to "just" unlock and forget it, because of all the apps that really really really want you to run Xiaomi and Google adwares and not your own OS

In France you can go very far (Paris <=> Barcelona, 1000km in 6h47, Lille <=> Barcelona 150km in 8h32), but only in the 30 biggest cities, and going from/to Paris. If you take two random points in the map (or even population), you'll likely not be able to do that route in a reasonable amount of time.

That's the OP's point. At the time, the community was split between word-level, which has the shortcomings you're describing, and byte-level which is uselessly compute intensive. BPE was the first reasonable in-between. BLT improves on BPE by having the the compression learnable rather than precomputed

You're confusing shiming with rewriting.

DirectX uses direct hardware access. DirectX uses direct hardware access. That doesn't mean you can't rewrite a DirectX-API implementation without direct hardware access. Likewise, Android's original implementation of MediaCodec uses binder. That doesn't mean that a reimplementation of MediaCodec API requires binder. The vast majority of Android public APIs do not assume binder. The only exception is Service binding, and even then, it's an assumption in name: It assumes that android.os.Binder will provide you an IPC. Most usages of android.os.Binder will be local to an app, so you can easily replace it with any IPC. Even the usage towards multiple app (whose only real usage would be Play Services) doesn't actually require binder. The requirement on that part is just the ""stable"" ser-des.

As an app developer, you (should) never connect directly to /dev/binder, because its API/ABI isn't stable. (it changed like 3 times in the last 6 years?)

I disagree. Apps barely use Binder directly, but mostly call framework jar (which yes will do binder, but since they are reimplementing framework jar that's fine). Intents and permissions can be implemented without binder as the API is quite semantic. It may happen that the app uses Binder for same-app IPC, but since app does ser-des itself, you can easily replace Android.os.binder by whatever IPC you want, The only "real" issue I can see , and you're right there, is Play Services. I think that handling that case specifically later (once floss apps/apps that don't require play services work properly), is not too horrific (it basically needs to compile the aidl into not calling binder, but redirecting it to a custom lib)

How is this relevant?

Their best models are not public weights but only behind their API

> A real-world web page compressed with WebP? Oh, how about the one you’re reading right now? Unless you use an old browser or have JavaScript turned off, WebP compresses this page starting from the “Fool me twice” section. If you haven’t noticed this, I’m happy the trick is working :-)

Well it didn't work in Materialistic (I guess their webview disable js), and the failure mode is really not comfortable.

> Or even an architecture akin to an atonishingly large number of RP2050's.

Groq and Cerebras are probably that kind of architecture

The "fun" part is that smartphones/tablets implement those features with S3 (CPU off, RAM in self-refresh).

Updates? Well here is an RTC to wake-up. Voice control? Well here is an always on audio dsp. Remote wake-up? Well here is a WiFi frame filter to trigger IRQ.

I think it isn't tractable on most laptops because of all the hardware that has been onloaded to software, and the hardware isn't capable of those hardware filtering, and partly OS and drivers are probably to blame too. An embesded OS takes under 1s to wakeup, so even managing TCP KeepAlives wih resume/suspend is realistic on those devices. Not so much when wakeup takes 10s.

I kinda hope that time-to-render is in their A/B rollout metrics to prevent rollouts...

> Want a perfect flight sim? Put a GoPro in the cockpit of every airliner for a year.

I guess that's the occasion to remind that ML is splendid at interpolating, but extrapolating, maybe don't keep your hopes too high.

Namely, to have a "perfect flight sim" using GoPros, you'll need to record hundreds of stalls and crashs.

Which is the reason you need to format your data to experiment with 16k

Google/Android doesn't care much about backward compatibility and broke programs released on Pixel 3 in Pixel 7. (the interdiction of 32bit-only apps is 2019 on Play Store, Pixel 7 is first 64bits only device, while Google still released 32bits only device in 2023...). They quite regularly break apps in new Android versions (despite their infrastructure to handle backward compatibility), and app developers are used to brace themselves around Android & Pixel releases

Yes. I see CAP theorem as a (perfectly right) answer to managers demanding literally impossible requirements

Usenet is my main source, but I'm not aware of anyone implementing streaming over it? Sounds nightmarish to implement really

Jelly Star is really small, I doubt it's usual as an actual smartphone (but I understand the "under-smartphone" usage). For the people who want the just-big-enough-to-be-usable-one-handed (for average man hands let's say), the upcoming Jelly Max should fit better.

My current daily driver which fits that just-big-enough is Qin 3 Ultra. Its size is perfect, but it is no longer available (unless you want to use their original firmware, which ugh, no)

(Also anecdote, I once ordered a phone from Unihertz, I never received it. I couldn't cancel the payment because it was a kickstarter with few months delay...I won't buy directly from them again)

Of course none of the devices I mentioned (both Qin & Unihertz) are compliant with GPL and release their kernel source code...

Yes, but they realized that at that point the problem is no longer the trains but people. You can't reliably board people that fast. IIRC, they moved from theoretical every 2 minutes to theoretical 2 minutes 30, and largely improve their throughput. But yes when there is congestion trains can go faster than 2 minutes 30 when relevant.

> Trains arrive as often as every three minutes during peak hours along the central spines of both the Elizabeth Line and the RER Line A.

I've taken the RER A everyday for few years (both and after automation), and that frequency combined with its size still puts me in awe.

My usual connection with RER A, I arrive at the middle of the train platform, and my next connection is at the end of the train. Statistically I reach the end of the platform before the train arrives maybe 5% of the time?

The frequency is so high that it takes more time to get at the right place of the train than to wait.

It's almost at the level of "don't think of the train, just your walking route".

(I'm saying almost because incidents still happen, and RER A can still suffer of "trains are running slowly because they are overcrowded because trains are running slowly" negative feedback loops, though it's usually resolved within 15m)

And this has the extra benefit that you don't give your website data to Google for free

In my business area (ISP), when doing carbon accounting, we have "scope 3" which includes the electric consumption we incur the electric consumption of our devices at user's home.

A first step towards reducing those externalities [1] is mandating that they power consumption Youtube incurs is accounted for. -- Another Youtube thing that made my computer screams is "theater mode", eating so much CPU for eye candy on so many devices ought to be at least declared.

[1] To explain the externality: Google probably does that because they make maybe +0.5% revenues by click to video, at almost 0 cost for them. Since the whole extra cost is paid for by the user (by requiring a bigger computer, by consuming more electricity). The price for the user to view a page without the embed and with it can be something like +20% at no gain for them. It's so small than no sane user make those computations, but if you start accounting like a company, you would see the difference. (Plus obviously all the ecological externalities)

> Government should just require open communication protocols/file formats, if a competitor is willing to host the same data at cost.

Well, that's what happened with the "Office Open XML" standard, which has been a catastrophe. Microsoft perfectly handled every country to have their ISO standard pass. Even though it was in violation of ISO requirements, which many countries voiced. Those complaints "somehow" disappeared. The fact that at ISO you're not allowed to divulge who is paid by which company might be related. Or maybe not. Either way, IMO, the conclusion is that you can't delegate democratic functions to a non-democratic organization.

But I wholeheartedly agree with you on the principle. Interoperability brings innovation and competition. Not lock-ins/walled gardens. And interoperability requires standards not ""technical specification"" which is the new slang for oligopoly.

My guess is that it's there for the publicity of the article. It'll get better press coverage mentioning ChatGPT than without it. I think their work is great and very important, so I'll let allow them that usage.

> Why are llama 3 weights listed as partially available ?

When you hover over it, it explains: "Requires signing consent form"

> And phi 3 weights are available.

Only the post-RL weights ("instruct") of Phi3 are available. There are two categories of weights in this table: LLM weights and RL weights. FWIW it says "RL". I can't explain the ChatGPT though, but i haven't read the article

Edit: Actually when you hover over API in ChatGPT it explains "API only accessible to commercial users". Can't say I really understand what they are trying to say. They want a completely free API?

How do you know it's carrier RCS? To the best of my knowledge they are only gatekeeping access to Google Messages private network, not carrier RCS? (Considering the very little number of carrier RCS that's not very relevant though)

> essentially unbeatable (unless there's a critical bug) due to hardware-backed attestation.

FWIW Google started enforcing those attestations like one month or two ago, and there are many critical bugs. I haven't kept scores, but some other people did : https://x.com/wanghan1995315/status/1803063996204912873

And please note that they only list big brands leaks. Since you can use any OEM's attestation key, /any/ OEM leak can break those so-called "security protections". Even after all security flaws, there is still social engineering. I guesstimate that you could ask an ODM's engineer for an attestation key for like 1k$ and share it to like 20 persons. (200 would probably still remain under the radar, but you need to be capable of keeping a secret with 200 persons)

Though the conclusion shouldn't be that attestation keys are insecure and we need a secure variant (because a secure variant is indeed coming). The conclusion must be that users own the device they bought. Not Google, not Apple.

> EU keeps people poor.

They keep people so poor that Americans need to hire European people for the high-end AI researchers, because EU still has the best education, despite having probably ten times less money. (Unless you consider being "poor" is exclusively about money and not quality of life, enlightenment and improvements to the society. In this case I'm happy to be poor but have all of those)

> - BPF maps being broken because someone at Mediatek ran some proprietary static analyser and blindly pushed some fix

Technically this one would possibly not be in Fuchsia, though Google let OEMs put so many hooks everywhere in the system that tbh it would still be possible to do this kind of fuckups

> - Camera only works properly in the OEM app

Fuchsia or not, if Google allows OEMs to add custom vendor calls from OEM app to camera driver, then OEM will still be allowed to do that. They could already forbid it in Android and choses not to.

> - GL drivers are upgraded once every blood moon and very OEM has its custom GL version

GL has nothing to do with the OS, GL vendors pretty much ship the same GL across all OS

> - Treble doesn't break because Samsung decided that mount loops were dangerously insecure at a time it wasn't required

This would definitely still happen (in other ways), by all the hooks that Google leave to OEMs to implement their own security systems (and Samsung is the company who brought SELinux in Android, so even though they do a lot of shit, let's not completely ignore them)

> - You don't need to keep workarounds for mainline kernels that you can't upgrade, because Google/Android forbids you to upgrade your kernel [1]

This one, ironically, would STILL HAPPEN, at least if we extrapolate how Android team work. When building Android from main, you get 10000 as SDK version number to explicitly mention that this is a development tree not to be used.

Fuchsia theoretical advantage should be that one will be able to upgrade the kernel without upgrading the drivers. But again let's extrapolate what Android team does: They create new API versions every year or more, and PLAN THE OBSOLESCENCE of those API versions within 3 years. So currently when an OEM write their drivers, they get kernel security patches for 6 years after the release of the "original" kernel of that version. With Fuchsia you get down to 3 years.

I want to re-iterate that even though from that perspective, ChromeOS' approach is ideal, it has issues wrt innovation. I believe that the ideal situation is an open but centralized approach like what we have currently with DKMS on GNU/Linux distributions. Except let it focus on LTS Linux kernel versions, and have flags on the DKMS to allow switching to newer LTS. Here "open" doesn't necessarily mean community-led. It can be very well just be that each vendor is responsible for its own product. So like Mali is responsible for their mali kernel driver, BOE is responsible for their panel driver, etc...