phh

Nit, but I think HDCP 2 is still cryptographically secure? No leakage, no known crypto flaws on HDCP 2.3 if i remember correctly.

That being said, It's still utterly broken because you can buy HDCP 2 disabler from Amazon for 20 €

The examples (except the very last ffmpeg command) are quite underwhelming:

- "The latest mp4...." well no, that ls command won't give the latest download, or rather, the latest in alphabetical order.

- tail command gives an error... can't you fucking tell which one? Initially I thought it found an error in the log, like a `modprobe nvidia` exiting 1 error and it was going to try to fix it.

- Searching for `sudo` usage was very painful in that screenshot, and the tool didn't ever come to recommend `sudo` themselves

- The list of files seem to have forgotten what we were trying to do (yes I do realize that saying "underwhelming" for a chatbot that can't keep context is so 2023)

- The only `sudo` URLs that worked were those where it's literally <baseurl>/sudo (well that's not surprising, it's a known flaw of most LLMs)

Also, I don't think there were any example (except ffmpeg) that weren't done more easily by hand.

That being said, the progression over time is impressive, and LLM are already useful for programming, maybe they'll be able to take the wheel the way this tool intent it to in just a few months.

> Why would it be done on the aircraft, and how?

I have the idea that a captain is responsible for its flight, and thus want to have as much information as possible. I think flights have their own full manifest anyway, so they have all the information you mentioned?

As to "how", I'm not sure I understand the issue, can't the same computations be done locally? The computations you mention doesn't sound too computing intensive.

I concur with sibling "Why does this seem so absurd to you?". You probably know real reasons for this not to be done from aircraft, and we're curious to see some.

My ECO101 lectures (I don't know if that's "standard economics") included government regulations to handle externalities (which can usually be summed up as "deaths")

> I sometimes wonder about file storage using a textual output format that can't be distinguished from normal user interactions.

You could use a reproducible LM (for instance using Bellard's NNCP as basis), and encode one bit in one word by taking the {first, second} most probable next word.

Rockchip devices have stellar mainline (that chip rk3588 doesn't have it yet), for business reasons (radxa relies on it for industrial support, Chromebooks push mainline very heavily). I can't speak for this new one, but previous rockchip flagship (rk3399) have exactly one binary blob, which is used for display port over usb-c. Everything else is supported as open source, and mostly supported mainline (Linux and uboot and atf)

Right, I don't really know how it is in other countries, but in France, the subsidies for poor people (that's obviously a shortcut and is more complicated) don't go through income tax but other systems. There is only one thing that applies to everyone which is work-related expanses (like the fuel cost to go to your work), but which has a 10% rebate if you don't declare anything, so you declare only if it's higher than that.

I would guess maybe 20% of people can go through the fully automatic part, but I have no source for that.

Nowadays, some people (like if they just have French salaries and no tax breaks) can even not look at it at all and their automatic filling will be automatically accepted

I perfectly understand not wanting to spend time on working around Safetynet, but in case you're not aware, I just want to point out that safetynet is pretty reliably broken (Google clearly doesn't use it for security. I'm pretty confident that it's 99% for passing audits, and 1% for shows). Current stats of the Safetynet workarounds is maybe 7 days of down time per year.

Also, my personal point of view of the matter is that apps that require Safetynet, 1. doesn't care about their users, 2. Do just-for-the-show security, and thus users would be better off not using them. I personally don't use any app that require it.

> I’d like to encourage you to advance the project, but with perhaps less of an ideological “this will prove X” slant.

Well, my current conclusion with my post is that wording is very very hard :-). What I said is "I want to show small-ish negative impact of a big tech monopoly". It will not prove it's all bad, even though it'll only give examples of where this is bad

> I think it would be very interesting to explore the boundaries of monopoly, and to look at cases where monopolies are probably a good thing.

Let's just say that the current tendency is to think that monopolies are fine, and I'd like to help reverting that. Yes your examples are worst discussing, and I have some of my own.

For instance, I definitely acknowledge that Android's monopoly helped whole unrelated sectors. But I also believe that innovation would be much better served if Android was opensource-in-spirit and maintained by something like the Linux Foundation.

> It’s going to be pretty easy to dunk on obviously harmful monopolies.

If it was, they would already have been ruled illegal? In Europe, I can't really name any "obviously harmful monopolies"

> Unfortunately, this subject area is full of strong emotions and opinions that make it hard for people to be objective.

I actually think it's not possible to be objective on that matter, hence it needs to be properly explained, to understand the limitations of one post (but the goal is to have many posts, so hopefully readers can reject the ones they feel is wrong)

> For example the article you link says that Google and Blackberry worked jointly on the 1:1 format phone, and jointly decided to stop working on it. That hardly sounds like an abusive monopolist.

Let's just say that I've seen a bit of first-hand, and a lot of second-hand of "Google working jointly with XXX", and in the vast majority, Google-side doesn't spend much engineering time on those issues. I completely agree this is not an objective point of view. This can hardly be proved, shown or explained, so I have no issue with you not taking my word for it. Hopefully if other people join this project, there might turn out /some/ people that you do trust?

> And sure, at that point Android was more popular than the BlackBerry OS. But this actually demonstrates healthy competition. I had a Blackberry for work, and so did all my coworkers. Blackberry was the dominant mobile platform once.

I wouldn't exactly call the replacement of BBOS by Android a "healthy competition", when the main reason Android won was that it was an OS completely free of charge, paid for by another recurring stream for the company. (I'm not saying Android was worse than BBOS, that I have no idea, )

> Through complacency and poor decision-making, they stopped innovating and competing. And thus, allowed new products with zero installed base on day one to come in and take their market.

That's irrelevant, and belongs to opinions.

One of my personal projects that I never pushed forward is a blog "a monopoly a day" (under-titled "keeps the EU away"). The idea is that everyday, I want to show small-ish negative impact of a big tech monopoly, and explaining it. The goal is that the sheer recurrence is enough to convince people of the negative impact on innovation and societal growth big companies have.

(That's with a pretty broad definition of "monopoly", including "user-specific monopoly" like you get with android / ios, notions that I would also try to explain in said blog)

One example:

> https://mobilesyrup.com/2016/09/27/why-blackberry-never-rele...

> I believe this one shows how a monopoly can prevent innovation. Blackberry with the Passport had a new form-factor. To make this phone worthwhile, it had to use a mainline OS. At the time, only Android with Google apps was available. However, Google rules back then couldn't allow this.

Would HNers be interested in such content? And in contributing to it? (my knowledge wrt monopolies is in my area of expertise, and let's just say I like being employable, so it's better if it doesn't look completely targetted)

Just from the name of it, Vulkan Video sounds like something that will be supported cross-platforms, windows, linux, android I'd say. that it makes much more worthwhile to implement than 30% of Linux.

Another possible guess, is that Google wants to start making their own CPU cores to beat Apple (I'm more along your guess, but I've seen so much Pixel-first AOSP development, that I have to doubt)

Google "wants" that, but doesn't seem to push forward on that matter. AOSP gerrit received risc-v jvm CLs 2 years ago from external contributors, and didn't merge any. (sorry, I have no source from Google's gerrit since they regularly clean it up, but you can find https://www.theregister.com/2021/01/21/android_riscv_port/ for related info )

Current state of Android RISC-V support 2 years after those ignored contribution is literally "we have a working libc", which isn't great. My understanding of Google's presentation is that Android 14 (Q3 2023) will have interpreter-only jvm support for RISC-V, no JIT/AOT. (I'm surprised there is no pure C interpreter that would work anywhere, but well). So decent RISC-V support in Android may happen for Android 15, so Q3 2024.

Will there be weird ABI/ISA issues that will need few versions to iron out? Hard to say, armv5 didn't go smoothly, nor armv7 (hi neon-less nvidia), and risc-v's modularity might prove to be challenging on that regard.

Overall, even though Google/Android doesn't seem as pushy on risc-v as they pretend to be, I'd say Google/Android will indeed be ready when the risc-v industry is ready for prime time.

I would say most people can't afford 25k$ investment cost for something relying on governmental decision that can change on a whim

It still does:

sudo LC_ALL=C /sbin/tune2fs -l /dev/nvme0n1 |grep 2022 tune2fs 1.46.6-rc1 (12-Sep-2022) Last mount time: Thu Dec 29 20:05:22 2022 Last write time: Fri Dec 30 11:14:35 2022 Last checked: Wed Aug 31 09:37:57 2022

(It looks like "Last write time" is actually "Last umount time", because it is not refreshed during usage of the FS)

Gotta say, I just don't understand STM32's "HAL". ST's headers has proper macros (and structs IIRC), and it's so much more readable by just using those macros rather than the weird indirection library which is still a 1:1 match with hardware registers

It doesn't go through walls, so they are pretty much the right tools for the job. They are known vulnerable to lasers, but well microphones themselves are, so...

Well, I read through most of the article, and felt like "well, this is work as intended". Except the "consider localhost for debugging" part, I don't see any bug anywhere, only UX choices.

In my understanding of TFA, every "trick" until "I can make silent calls" were explicitly made available by Google on purpose and could have been done without reverse engineering by using the standard smartphone Google app (except for wifi deauth -- but the resulting behavior of instantly making an AP is wanted by Google. I personally would have made this happen only on startup, not even for security reasons)

And well, that's the scary part I guess: that this system is so big, that Google can't control all the ins and outs of the various UX choices.

One thing I don't understand, is that Chromecast were historically famous for pairing over ultrasound, guaranteeing physical presence. And to this day, ultrasound support is still a hard requirement for all Google/Android devices for that feature. Has this been completely abandoned? Don't Chromecast <=> Google Home team discuss?

Tell a human 200 years ago that we can access any knowledge of the humanity within minutes, that we can travel at 900kph, that we can drink sea water. They'll tell you that we are indeed super-humans.

Considering how we do limb prosthetics, we won't know how to interface a brain with a computer. We know how to make a computer compatible enough for the brain to interface with the computer. This can be the way this plays out.

Arguably, we already did that (make an interface that our brain adapts to): programming languages, keyboards, are already man-made interfaces our brain adapted to.

> Even ordering a burger is tricky, why are there sesame seeds on a burger bun?

Sesame seeds are flavor enhancer, just like salt. The "simplest" salt-less bread simply replaces salt with sesame seeds. Of course burgers will use all the tricks they can to improve flavor, hence the sesame seeds on burger buns.

All those businesses (except GCP) boils back down to ads. They still manage to diversify better than Facebook, because they diversified where they show ads, but it's still pretty much just ads.

I didn't expect such attacks to exist, thanks for bringing that up. However that Wikipedia page seem to say sha-256 is ok since it's truncated?

FWIW, on mobile, I use https://f-droid.org/en/packages/io.github.hidroh.materialist... rather than the website, so I don't have that issue.

> And you don't need to have any form of licence to drive one in France!

FWIW, that's wrong: only people born before 1985 ~ (i don't know the exact date) don't need any license. People born after that do require a license, which is much much lighter than standard driving license in France, but still requires several hours (I think it takes a whole day?), which I think is equivalent to what actual driving license in some countries.

This is a real problem, though the problem is not technical, it's purely contract/legal: Disney+, AppleTV (all content providers actually) refuse to allow third parties to know what you've watched, because viewer data is closely protected

That's why an opensource ToS-violating assistant has chances to work better than legal ones, they can just scrape all those infos off internet. But then, once you go into that grey area, you just end up pirating content already.

PSA: I strongly recommend not to use Cobalt (unless of course you are a Google employee, with support from Cobalt team).

Cobalt's roadmap is 100% Youtube on TV roadmap. I've never seen anyone use Cobalt professionally for anything else. Even Android TV doesn't trust Cobalt for anything but Youtube.

It mentions "subset of HTML5" which begs the question of "which subset", and the answer is pretty much "whatever Youtube on TV" uses.

Please note that I'm not speaking of the actual quality of the project which in my experience is fine.

If you're wondering what to use then for an embedded Linux web browser: I don't have a professional experience on it, but most people I know use WPE WebKit/COG

It's definitely fully supported, it gets many upgrades and has a pretty long-term and serious roadmap.

I strongly recommend not to use it though.