phh

cf sibling's comment: You need to factor-in credit's price. I've been looking for a flat near Paris for 2 years, and sure the prices are lowering. But still, the cost (either total cost, or percentage of my salary) for me increased.

My mental model of housing in my area is that I have the n-th salary in that area, so I get the n-th best flat. The pricing will then be exactly what I can afford (which is legally 35% of my salary here). What changes is who gets how much, 3 years ago it would go at 95% to the previous owner, nowadays it's 70%.

It's a pretty weird subject: the document that has been mentioned in the press about that requirement doesn't exactly say that Google app are required, it says that when you do an "Android" it must always comply to Android APIs. Which can be done without Google apps. BTW that agreement still exists even where it was deemed anti-competitive, but in domains where Google isn't a monopoly (like cars).

That being said, it's Google. Even you didn't sign anything that says you're not allowed to do Google-less Android, when you launch a non-Google device, Googly devices may just "mysteriously" fall into "oops sorry we are understaffed, we don't have time to handle your requests".

<Emergency Calling app's team> "We've improved the usage of our app by 75% and average session time increased from 3s to 15s!"

> To Google's credit they have already done a _lot_ of positive work in that area as I understand it

They haven't. I've extensively worked on their Project Treble, and they did a beautiful work to perfectly versionize every behavior OEM might depend on, or version driver APIs. They could use that to provide long term support (which is what I do in my own project, the foundation is very sound), but in practice they use it as a way to obsolete code faster:

Before Project Treble, Android kept whatever code was in use. So if some OEM was still using a 5 year old code path, and it was still working fine it would remain.

After Project Treble, every driver API has a new version every year, and the older ones will be deprecated (read: purposely broken or completely removed) within 3 years.

Before project treble, OEMs could maintain the Android for their platform quite effortlessly for 5 years, nowadays they have to rewrite whole parts of drivers after 3 years.

someone will come and say that since Project Treble OEMs have been upgrading for longer. But I consider it's completely a matter of timing, the smartphone market stagnating. Look at nVidia Shield and fairphones for reference.

I'm pretty confident that by most metrics custom ROMs are less compromised than OEM ROMs. It will have less malwares, I better sandboxing, less 3P backdoors , more up-to-date security updates.

1P here being the user/owner of the device

> Unless you care about your phone working as a phone. 2G was discontinued years ago, 3G is rapidly being dropped by the carriers and how much longer before 4G is discontinued?

First 4g devices were released in 2012, in 2014 you could find sub 150€ 4G devices. If you bought the last 3G phone in 2015~ (there were still 3G phones after that, but nothing reasonable), 10 years of network support is still reasonably within reach.

In school, I handled the network for students, we had a /22. I was still afraid to use .0 and .255.

I agree it isn't snake oil, but from my PoV it's barely moving the scale back from the "use an E2E IM to protect against tour state", while either recommending closed source apps or close source origins (downloading an open source app from Google Play Store or App Store who owns the encryption keys is pretty much the same security as close source app)

This 100%.

I'll complete with patterns I'm using for exit traps:

- for temporary files I have a global array that lists files to remove (and for my use case umount them beforehand)

- in the EC2 example, I add a line with just "bash", so I have an env with the container still running to debug what happened and I just need to close that shell to clear the allocated resources

> A static list of required capabilities in some ELF header would probably be better.

I think I agree, the thing is that it's a kind-of security issue. I suggested pinning, because it requires CAP_SYS_NICE, which is a feature: If you allow apps to freely declare their usage, they will end up being scheduled not fairly, because system will stick them to P cores.

That being said, you could have indeed an ELF header mentioning since, and then ignore it if caller doesn't have CAP_SYS_NICE. I do feel using an ELF header for that is weird, but my knowledge of ELF is way too little to judge.

Another thing that could work is using file-system attributes or mode (like setuid), but I think FS support of attributes is at best spotty, and I doubt modes can be extended.

I don't really know how CPUID works, but I'm guessing it can be trapped by Linux. So I think that a first "stupid" implementation would be for Linux to report in CPUID intersecting section of CPUs on which the process is allowed to run. So if you want to run AVX512, you first need to pin that process to an AVX512 CPU. You would be able to find an AVX512 CPU by checking in /proc/cpuinfo. (even this "simple" variant is far from first because the cpuset can be changed dynamically in various ways, like Android would move a process from foreground CPUs to backgrouns CPUs using cgroups)

When mainline tells you "your hardware is broken", what kind of contributions do you expect exactly?

> And then their rushed efficiency core strategy effectively disabled AVX-512 just as they were getting back on track.

I partly blame Linux for that. I remember asking at Kernel Recipes about supporting truly heterogenous multi - processor systems and got shrugged "don't buy broken hardware". Back then, it was for a Broadcom home gateway product, which has an asymmetrical dual core, one with a FPU, the other without. Since then we have seen many examples of such assymetry: most HMP smartphones have asymmetrical instruction set. Mono (and probably all JIT VMs) hit issues of varying cache length so the perfect abstraction is already gone. And now we have Intel E vs P. This is a rather hard problem, I won't pretend otherwise but the amount of dead silicon, and lost power efficiency accumulates significantly.

"HDR" contains multiple components: - Electro-Optical Transfer Function. That's the famous "gamma" of the display which is no longer a gamma - color space (which real-life color does RGB = 100%, 0%, 0% match) - Absolute brightness. There are metadata in the video files that say that RGB=100%, 100%, 100% mean 2000cd/m2 (and gives the average frame brightness like 10%, which helps scales for displays not capable of 2000cd/m2 everywhere) - Increased bit depth

Display-P3 is only the color space (and maybe the EOTF). This video uses the "absolute brightness" feature of HDR to increase brightness.

Having tested Meta Horizon (which I think is supposed to be current Meta's metaverse? But I could be wrong), It's completely user-generated content, there is very little company-generated content.(there is very little content altogether but that's another joke) So I have a hard time understanding that comment...?

That's literally Dunning-Kruger effect.

That being said, I concur that C++ is the language where "we need some rules" is the most prominent. C++ has awesome features, but the number of people on the planet who know all of them is way too low to rely on them (you probably can't hire any of them anyway). But a team of 10 peoples is likely to know a lot of them together, so you need to work with the intersection if you want your code to be maintainable

I have no killer game, but I enjoyed many games. The most notables for me were I expected you to die series, A Fisherman's tale series, the last clockwinder, Synth Riders, Superhot

> which has wink-wink tacit endorsement from the devs.

Is that true? A kinda competitor to Beat Saber is Synth Riders, and it's not wink-wink, there is official support for custom songs (and mods I think? I'm not sure). And when I get back to Beat Saber (because I like both Beat Saber and Synth Riders' game play), I feel like I'm owning an iPhone: a beautiful object but I can't actually do what I want with it

Yup I completely agree with you. Quest 2 is an awesome game console because of the immersion. I expect AR to be as gimmick as it has been on smartphones (though I'll probably find a game or two that will be fun for few hours), but passthrough is a useful feature. My expectations on Quest 3 is exclusively better performance, to have a wider range of games.

I perfectly agree that the amount and quality games that can be squeezed on Quest 2's GPU is freaking awesome, but still PCs have better games, and I'm not just speaking of graphics. For instance "open world" games like Derail Valley doesn't seem possible when I see performance of Synthriderz on long "experiences". It looks like loading anything that isn't already in RAM is painful (which is weird for a unified memory architecture, but anyway)

It basically doesn't say anything about what's new (besides color passthrough), that's rather annoying.

I love my Meta Quest 2, and I'll blindly buy Quest 3 as soon as available. It's an awesome game console, and the games' quality is very consistent (I also do PC VR, and even though PC VR has some neat stuff, it's much more effort. I usually can do PC VR only 1 hour in a row because any frame jitter gives nausea, while Quest manages 1 frame drops per hour).

That being said, I'm expecting to be let down: - No more Carmack. I'm pretty confident he helped push quality forward, and quality is really what puts Quest 2 ahead of its league. You must really have 0 head tracking issue and 0 frame drop. - the design with camera islands screams at "designers wanted a say", but they forgot practical use. Quest 2 was smooth, which makes it easy to put into a bag and out, and camera' lenses were kinda protected. Here you've got the worst part of all. If my smartphones are any reference, the ones with islands are scratched within 6 months. My Quest 2 is 2 years old and looks to be able to sustain 5 years without a hitch. I'm not optimistic about Quest 3.

That's especially true since they won't actual compete since they'll be 5 times the price of the other. The Quest will be the demo for the Apple VR headset, and the Apple VR headset will give VR hype that will boost Quest. If they weren't just FAANG amplifying FAANG, I'd be happy to see such a win-win.

I get it. A gamified version of all the frustrations I have with mobile UX and my fat fingers exaggerated to absurdity. Personally I take it as art, not as a game. I won't play it for more than 3 minutes.

To quickly lower expectations before reading the article:

> Every year with these Arm flagship chip announcements, the company also includes a wild design for a giant mega-chip that usually never gets built.

That being said, this 14-core figure is when doing a full-Arm SoC (with Arm internal bus). SoC vendors are still allowed (AFAIK [0]) to do their custom interconnect that goes higher than that

[0] there have been rumors seen here that Arm is pushing towards a model where SoC vendors must do all-Arm components. That still sounds weird to me, and I'm not witnessing any actual effect of this, so I still highly doubt it.

I hate most usages of javascript, and I want to be running only opensource components that I trust. So I should agree with you. But that doesn't sound realistic to me, even in dreams.

> Hit play, and you get more than 24 hours — 24 hours, one minute, 27 seconds, to be exact

That's 24*3600/(30/29.97)+1 and I think that's beautiful in itself (though probably not on purpose)

Well, I already said it :P RK3588's NPU can only do convolutions and a small list of activation functions. Realistically it's usable only on image (2D, 3D data). The software side is pretty weird: It's amazing the amount of models they support despite the limited fixed-hardware function, but there has been literally 0 development in the last 6 months and it does have a lot of bugs that doesn't seem hard to fix. Even when it comes to images, it doesn't support changing the resolution of the input (you need to ""recompile the model"" for that), which is super weird since hardware pipeline doesn't care much about the size.

Anyway, I really don't recommend it, unless you're making your own model, you know before-hand what's supported and what isn't, and your input is fixed resolution (which is a pretty fair usage in an embedded system) (fixed = doesn't change at every frame. handling hotplug from one webcam with a resolution to another with another resolution is fine)

I think looking at the examples give you a reasonable show of what it can do: https://github.com/rockchip-linux/rknn-toolkit/tree/master/e... It's mobilenet, yolov3, resnet50. There aren't more examples because they didn't had more examples. There aren't more examples because that's pretty much all you can reasonably run.

As far as I can tell, modern image models using transformer/vit won't be runnable on it. (it acts enough as a coprocessor that it's possible to do some parts in CPU some parts in NPU - and Rockchip framework handles that -, so maybe it's somehow possible)

(Note: I say this as a huge Rockchip lover, their mainline support is top-notch, they make very durable product (their 2015's RK3288 is still far from obsolete), and I bought a RK3588 SBC to play with a NPU accelerator (whose full specification is publicly available btw), in the hope to have a self-hosted LLM voice assistant)

There are very different architectures in the wild. Some are simply standard GPUs (maybe with additional support for bf16/float16) (Rockchip RK1808 has one like that). You give it a list of instructions pretty much like a CPU (except massively parallel), and it'll execute it. BTW when I say standard GPU, I'm not saying "kinda like GPU, but really literally GPU architecture. Linux mainline support for Amlogic A311D2's NPU is 10 lines, and it's declaring a no-output vivante GPU.

Some are just hardware pipeline to compute 2d/3d convolutions + activation function (Rockchip RK3588 has one like that). You give it the memory address + dimensions of the input matrix, the memory address + dimensions of the weights, memory address + dimensions of the output, which activation function you want (there are only like 4 supported), then you tell it RUN, you wait for a bit, and you have the result at the output memory address.

(I took Rockchip example to show that even in one microcosm it can change a lot)

And then you can imagine any architecture in-between.

AFAIK they all work with some RAM as input and some RAM as output, but some may have its own RAM, some may share RAM with the system, some might have mixed usage (RK3588 has some SRAM, and when you ask it to compute the convolution, you can tell it either to write to SRAM or system RAM)

It's possible that there are some components that are border line between ISP (Image Signal Porcessing) and a NPU, where the input is the direct camera stream, but my guess is that they do some very small processing on the camera stream, then dump it to RAM, then do all the heavy work from RAM to RAM. I think that Pixel 4-5 had something like that.

Yeah that section isn't very clear. Also, the article doesn't seem to explain what NF4/NormalFloat is at all? I would guess it has something to do with the position of the value on a gaussian, but that's just a guess

> If I say "it's too chilly in here" in a house with only lights, it will turn them on as a way of "warming things up".

Thanks for the example that's interesting.

FWIW, this is pretty much what has been described as "waluigi" effect a bit extended: in a text you'll find on the internet, if some information at the beginning is mentioned, it WILL be relevant somewhere at some point later in that text. So an auto-completion algorithm will use all the information that has been given in the prompt. In your example it puts it in an even weirder situation where the model the overall model information (the lights, and that you're cold and nothing else), and it must generate a response. It would be a fun psychological study to look at, but I'm pretty sure even humans would do that in that situation (assuming they realize that lights may indeed produce a little bit of wattage of heat)

Not really cookie-less and it can be considered a regression compared to cookies because of JS, but something that can work is doing stats + anonymization client-side.

You can store information client-side, without sending them over network, but randomly send digests back to your server.

For instance you can store a counter of the times the user went to visit the website, and randomly with a 1% probability send that counter to your server. (It's better to make it random, because if you send every +=1 you would end up being able to track users).

At my work, I do a lot of statistics of user usage, but I always work to do my best not to leak PII. I'm not a security or privacy researcher, so my work is probably not great but still, the way I do it I believe is largely private:

- No unique ID sent, but a daily digest (some people send every single event to their statistics server, and thus need a unique ID to know how many time one person did one action. With a digest that already counts the actions there is no need)

- bucketized persistent data: for example the available storage size of the device the app is running on. Sending precise value would make it easier to track digests from one day to the other and track users

- For booleans, add some white noise (because 20 booleans is enough to identify someone)

- For open-ended information (for instance the list of countries contacted by your SMS app), booleanize it (one boolean per country, cf previous line), and maybe keep a counter to know how many you didn't take into account to know whether you're still missing a lot.

Yes overall doing it with no PII requires much more work, but then Big Tech (and smaller techs like Clearview) clearly showed that any PII can and WILL be used against their users. The best way to never leak user's data remains to never have them in the first place.