thyristan

The purpose of Android for Google is to push users into paid services, Google search, collect some play store fees and some data. None of that actually requires Android to be really open. Just saying something about "open" works as advertisement though...

Wikipedia (https://en.wikipedia.org/wiki/List_of_open-source_mobile_pho...) lists /e/OS, CalyxOS, IodéOS, LineageOS, postmarketOS, Ubuntu Touch, the latter two being non-Android, the rest Android derivatives on Fairphone 5. Fairphone 6 has only /e/OS and IodéOS listed at the moment, but that will probably change after some time on the market.

There are also various reports of things like running e.g. Fedora on an FP6, https://www.notebookcheck.net/Fairphone-6-turns-into-a-Linux... or Debian on FP4/5, but those generally aren't something that is usable due to lacking support for basic things like calls.

Fairphones are easy to unlock, repairable, have a long lifetime and offer a variety of different operating system distributions.

Theoretically, you can define systems of measurement where a lot of seemingly separate things fall on the same units and dimensions. There are "natural units" in physics where you take the fundamental nature of particles and relativity into account and make some convenient choices for some physical constants such as the speed of light c := 1. Then the speed becomes dimensionless, length and time have the same unit and dimension (a length of 1eV is a time period of 1eV), and almost all units are simply derived from a measurement of energy (electron volt, not as basic as people would like, but useful enough).

https://en.wikipedia.org/wiki/Natural_units

> Next time you are measuring traffic to your website consider using the appropriate SI unit for measuring requests per second: the Becquerel.

Great idea, I will definitely do this!

In a very awkward way: rad is m/m, which is 1...

> The individual wasn't the one who truly decided the essential means and purposes beyond personal use

The user is supposed to have read Meta's terms and conditions and agreed to them. Of course nobody does that, but that doesn't absolve of the responsibility, it rather means that the user who uploads stuff to Meta does things in full knowledge and willingly or carelessly. It just might make Meta liable as well, because naturally their terms were sneaky, hidden, unclear and probably illegal.

And I'd guess that Meta Ireland has been sued often enough that they have some export clause deep in their conditions as well, which the user should also have read and agreed to.

> While recording by these might not always implicate GDPR directly (as it might be exempted under household exemption or the broader allowances given for journalistic purposes)

I'd guess that the glasses first transfer the recordings to Meta who process and store them abroad for various commercial purposes. That way of working can never fall under the household or journalistic exemptions. And per GDPR the owner of the glasses is on the hook for whatever Meta is doing, because the owner is (by GDPR) contracting Meta to do data processing for him/her.

That's the first search engine hit I've pasted. The cheap ones that work just as well are single-digit prices. And usually there is one in every toolbox on the shop floor.

Edit: if you need proof, 2 for 6.50€, shipping included: https://www.ebay.de/itm/277671545941

You are right.

Not an LLM problem, just an undecaffeinated meat brain and some faulty memories. I've misread 'When PS=0, the page table address field represents the physical address of the page table that manages the four megabytes at that point.' to mean that when PS=1, the address isn't physical. But PS is page size... And I somehow remembered that you could induce pagefaults when walking the page tables...

Sorry.

> Page tables are physically addressed

Nope. Not on x86. You can use either physical or virtual addresses at your choosing. Consumer OSes use virtual ones, so you can swap out page tables (yes, really!). See https://wiki.osdev.org/X86_Paging "Page directory".

Yes, it is.

All the siblings might talk a lot about "but ruggedized!", "but realtime!", "but supported!".

But in many cases, it is just a case of vendor lock-in. Ruggedized is just a casing and decoupled I/O-ports, you can get that for your Raspberry Pi. Realtime is a concern, but modern PLCs aren't really realtime anymore. Those are usually some big multicore non-realtime ARM, plus some small realtime-capable I/O-processors that do the really time-critical stuff. Or even just a CPLD to implement some trivial ladder logic cycles. Support matters, but if your PLC vendor goes bankrupt you've drained a few millions. Might be better to get something cheap where you can just stock up a few hundred replacement parts for cheaper.

That's why actually, a lot of smaller PLCs are Raspberry Pi CMs now. The vendor won't tell you, but if you open them up, you'll see.

And the big customers also wised up to the PLC scam and are now moving towards putting their control tasks on standard x86 hardware in the shop floor basement plus realtime ethernet with cheap I/O extenders on the shop floor. Which is why the big PLC vendors now try to sell "virtual PLC" to those customers, so they get at least a little money instead of none ;) https://www.siemens.com/en-us/products/simatic/s7-1500v/

The PLC is usually in a control cabinet that can be opened by a control cabinet key:

https://www.knipex.de/schaltschrankschluessel?v=2921

Real locks in such systems are rare, sometimes even disallowed. Usually, a lock with a real key is only used to temporarily prevent switching on a machine during maintenance or such.

Depending on his interpretation of the rules about trapped instructions, one could just build a loop in the x86 page tables. Those are usually a tree linked by pointers, and any page table lookup can create another page fault that creates another lookup that...

Leads to x86 page table MMU magic being turing complete: https://github.com/jbangert/trapcc

And the simplest thing you can do on such a system is just to loop indefinitely, thus creating a simple instruction with a memory access (mov or anything, doesn't really matter, even the instruction fetch for a nop would work) to take infinite time.

We even had open APIs for every bank in Germany, in the form of HBCI and FinTS. With fancy things like optional RSA smartcard auth. The EU killed it all in the name of "omg, security!" (a total bullshit argument if you've ever looked at the specs), now with the new PSD2 the only ones getting proper API access are lots of shady payment providers, credit databases, data brokers and the like...

I guess we just need the DBUS developers to get their heads out of their asses, that's all: https://lkml.org/lkml/2015/6/23/657

It is fine to have the fragment stripped before sending it to the server. What I meant was that client-side parsing of TSON in many languages will be hindered by the client-side libraries stripping the fragment far too early. Because you will need that fragment part for validation, but if your parse_url-function dismisses the fragment because nobody ever needs it...

Fragments are useless outside a browser and lead to problems. A lot of command line and library HTTP agents ignore the fragment part of an URL, so you often might encounter everything after # stripped. Thus forcing you to invent yet another HTTP client/agent/URL library in a ton of languages.

Dislike.

No comments means that one cannot use it for configuration. Properties repeat the XML mistake of the attribute/content dichotomy.

And trailing commas as a syntax error prevents easy sorting/appending/editing of arrays.

And it doesn't fix a ton of JSON problems like strings containing newlines, quotes and the like, while introducing a ton of new problems, like the dependency on obscure Unicode features to elide quotes. This will lead to TSON homoglyph attacks.

Domains with stricter DMARC that isn't on 'none' are in my experience more likely to be spammers than desirable email.

Yes, they are a good option, provided you get one that has a condensate drain. Always use a piped drain, never just a tray that you have to empty, make the hose wide enough and clean it every few months, because algae will clog it if you don't, and then you'll have your own privat lake. But that's basically the same as for any air conditioning.

Insulate all piping properly, the outdoor part will freeze in winter, and the indoor part will drip in summer if you don't. The best products for this are foamed rubber based. Make the insulation seamless with the right glue or tape, every opening will drip.

Add manual or automatic valves to shut off the heating loops in summer, so you don't accidentally get cold water in there. Your cold water loop might also need an extra circulation pump, depending on how you run your piping, but that's hard to say without a lot more detail.

FCUs are available in the same form factors as indoor units for refrigerant-based systems, including a thermostat remote control, e.g. https://www.sinclair-solutions.com/files/user-manual-en/fan-... . But get one from the manufacturer of your outdoor unit, so the communication lines work, e.g. so the indoor unit can instruct the outdoor unit to start/stop/regulate.

The problem is, if you feed cold water into your normal heating pipes, all the piping and radiators will get wet from condensation. So you would have to have a regulator that measures air moisture and temperature in all your rooms and only feeds water with a temperature above the dew point. This is possible, but inefficient and (especially on hot+wet days) doesn't cool very well.

The possible real fixes are either to section off your water circuits in summer, and only run the properly cold water through FCUs, wall or ceiling loops.

Or to get a multisplit heat pump, use a normal refrigerant-air indoor unit to cool and a refrigerant-water indoor unit to heat the water loops.

It would be a market-based solution if the state wouldn't interfere with the markets in major ways. E.g. many battery projects in Germany are nonviable due to the fact that some less-efficient but cheaper battery technologies are verboten. Meaning the market gets screwed again. There are also fees and taxes on power transit that are set up in such a way that energy storage is disadvantaged compared to energy production, especially gas-based energy production. Hydro storage e.g. is comparable to gas peaker plants in the quickness of powering up/down, but hydro storage pays transmission fees twice, once to charge, once to discharge...

Nuclear. The Schroeder government initiated the German nuclear phase-out (which was later reverted and re-reverted by Merkel). But rumor has it that the nuclear phase-out wasn't only motivated by the greens being anti-nuke, but also by Schroeder being interested in pushing gas instead.

Btw., after his chancellorship, Schroeder got a post at the Russian state gas supplier Gazprom.

The problem there is the "national imperative" part imho. All EU politicians are hell-bent on ignoring any kind of market-based solutions, doing everything through regulations and picking winners. So there will never be a proper market equilibrium and therefore prices will always be higher than in places without all those regulatory interventions.

Investment won't help there in any way, because if that investment were worth it, it would already happen because of market forces. If it doesn't happen on its own, then the state (doesn't matter which level) has to do it, which means using tax money, which means that prices will rise. So that state investment will further skew the market equilibrium, putting the EU further behind.

> The basic GCN microarchitecture underpinned every single one of AMD’s compute accelerators for nearly 15 years [...]. With CDNA5 AMD has moved over to a microarchitecture that is based on the RDNA series putting a bookend to the long-lived line that was the GCN microarchitecture.

So everything is new again. Will this be another "buy now, have ROCM work in 3 maybe years if you are lucky"?

The people and birds (and I think the buildings as well) were selected by a committee beforehand, to make sure they represent all of the EU, aren't controversial, yadayada...

There were some clearly superior suggestions they left out: https://xcancel.com/The_Davos_Man/status/2080383908823081426

;)

I'm not sure either, the forgejo/gitea fork seems to also involve a lot of activism and interpersonal drama. And codeberg shares a lot of the people involved in that drama on the forgejo side. The gitea/opencollective side has it's own share of "difficult" people.

So I know of no technical reason why any should be better. And the potential for drama and conflict inherent in the developers of both projects make me wary. In the end I decided to use forgejo, because absent a corporation at least the possibility of a corporate rugpull is reduced.

As opposed to business-lead stuff where their credit card company, VC or possible future owner says that you are an undesirable customer and need to get bent?