This is honestly really cool! I've heard praises about Zig's comptime without really understanding what makes it tick. It initially sounds like Rust's constant evaluation which is not particularly capable. The ability to have types represented as values at compilation time, and _only_ at compile time, is clearly very powerful. It approximates dynamic languages or run-time reflection without any of the run-time overhead and without opening the Pandora's box that is full blown macros as in Lisp or Rust's procedural macros.
> Wait, if I recall correctly, covariance has long been established as a mistake.
Perhaps you're just missing some words here, but, just for clarity: it doesn't make any sense to say that covariance is a mistake. Covariance applied in specific places, like Java's mutable covariant arrays which leads to unsoundness, can be a mistake, but covariance itself in fine and essential in languages with subtyping. Function parameters should be covariant, function returns should be contravariant, mutable data structures should be invariant, etc.
> I'm not very familiar with these relations, but shouldn't function returns be covariant? `String => Cat` is a subtype of `String => Animal`?
You're right :) I mixed up covariance and contravariance for function parameters and return value in my comment.
> For function parameters, doesn't it depend on how the parameter is used?
I don't think so, but maybe there's specific circumstances I don't know of? Function parameter types is a constraint on _input_ to the function. Changing that to a subtype amounts to the function receiving arguments that satisfies a stronger constraint. That seems that something that would hold no matter how the parameter is used?
> > For function parameters, doesn't it depend on how the parameter is used?
> I don't think so, but maybe there's specific circumstances I don't know of?
I don't know specific circumstances either, but I presume they exist because of things like Dart's `covariant` keyword [0], which makes function parameters covariant instead of contravariant.
Copy(adest, asrc); // No! - How would Copy know how to copy `A` values when it only knows about `B`?
Copy(adest, bsrc); // No! - src argument is OK, but how can it downcast them to `A`?
Copy(adest, csrc); // No! - Same as above, and src elements must be at least `B`s`.
Copy(bdest, asrc); // Ok. - Any `A` in the src are interpreted as `B`s.
Copy(bdest, bsrc); // Ok, - all values are interpreted as `B`s.
Copy(bdest, csrc); // No! - Argument elements must be at least `B`s`.
Copy(cdest, asrc); // Ok - values are interpreted as `B`s in src, and as `C`s in dest.
Copy(cdest, bsrc); // Ok
Copy(cdest, csrc); // No! Argument elements must be at least `B`s`.
If the `dest` argument were contravariant, it would permit invalid copies and forbid valid ones.
Maybe this is intentionally introducing logical unsoundness into Dart's type system for pragmatic purposes, perhaps supplemented with some implicit dynamic checks?
However, outside of the function, when calling it, the opposite is true.
let result = foo (arg)
;; String <: arg
;; result <: Animal
It's easy to get them mixed up when looking at it from the wrong perspective - but we should be looking at functions from the outside, not the inside - so yes, parameters should be contravariant and return types covariant.
My understanding is that it will be much harder as ARM is way less standardized than the Intel x86 platform. This is something that Linus Thorvalds has talked about in the past [1]. Think about how huge an effort it is to get Linux to run on Apple’s ARM machines or how some distros have a Pi specific variant. I guess getting macOS to run on other ARM machines could be similar challenging.
I would love to know more about this. Would it not be (at least theoretically) possible to hackintosh ARM, as Asahi Linux reverse engineered at least some parts of the M series?
Absolutely. I did a little bit of iOS development at some point and was genuinely shocked by how bad the documentation was and by how often WWDC videos was the best documentation available.
To give a concrete example: At WWDC20 Apple showed off a new Core Data feature called "derived attributes" [1]. Only many months later did they add the bare minimum of written documentation covering a fraction of what was shown off at WWDC [2].
> Suppose the war ends. Will the Europeans keep boycotting the cheap russian gas?
I think they absolutely will, yes. It will cost some money, just like spending more money on defense will, but from what I can see, no one in the European politic elite imagines a world where we can go back to buying gas from Russia.
I don't really understand the take here. The post makes it very clear what is concrete evidence, what is speculation based on that, and the reasoning is much better than what you give it credit for. For instance, what would you suggest the "remote-connectivity-api" SSH endpoint URL and the authorized public SSH key is for if not for remotely SSHing into the bed's computer?
This is a Linux image that is, somehow, remotely flashed onto the bed. He found the SSH key on the filesystem.
1. He didn't even bother to check and see if the bed is running an SSH server - ten seconds with nmap could have told him this!
2. Essentially every one of these beds would be behind a NAT and thus the SSH server which he didn't even bother to look for would not be accessible to the internet or to the nefarious engineers he imagines have access to the key - he ignores this fact.
3. The fact that the firmware includes the URL of a specific external endpoint, suggests that the bed connects _to_ that endpoint, not that this is somehow used to screen incoming requests by reverse DNS lookup or anything like that. The architecture he is supposing exists (all remote access requests must come from a host whose reverse DNS resolves to this host?) makes no sense.
4. The fact that the public key exists on the filesystem means nothing if no SSH server is running, or accessible. It might be used, for instance, as part of the manufacturing test process or a maintenance procedure, and then disabled. The SSH public key on the filesystem isn't necessarily related to the JSON config file for their own application which he found!
5. SSH keys don't have "email addresses" associated with them, they have a plaintext field which is used merely for identification purposes, and this is commonly used for the _user account_ that created the key. But it's not an email address and even if it were, it doesn't mean that that email address, much less every engineer at the company, somehow has access to the key!
The sloppiness and level of jumping to conclusions here, for a supposed security company, is ridiculous.
Thanks for expanding! I think your original comment would have made more sense with some of these arguments included. Point 1 is especially prudent. It really would have been trivial to see if the bed is actually running an SSH server on some port.
I think the key feature is _cooling_ the bed, with warming secondary to that. That arguably sounds like a great nicety to have, notwithstanding all the downsides mentions in the post.
So now your getting hacked and breathing in toxins while you sleep. Hacked up the arse and in the mouth too. Nice.
Yeah, no thanks. I try to make my bedroom as technology free as possible. Apart from a digital alarm clock; at night I put my phone on aeroplane mode and place it outside my closed bedroom door.
It's the best I can do with today's bullshit tech. I've never had a problem with not having a cold bed, so maybe it's the next best thing after the bidet.
Cold cannot be "made", as it's an absence of something (energy), nor can it "leak" as a result.
I take what you mean is that there will be a refrigeration loop involved, and in that, a refrigerant. Just like all substances, refrigerants can be toxic, sure, but that alone is not what makes a toxin [0]. It's also not a binary thing, and between air conditioning and refrigerators, an appliance like this I don't see why would stand out.
I further haven't got a clue what microplastics having been found to pass the blood brain barrier have to do with this, or how you're able to determine whether that applies to me or not, specifically.
> All their other “products” are just suction pipes for hoovering up that data.
I don't think that's true for their VR/MR hardware. That's Meta's attempt to get a product that is _not_ like that, but which instead gets them in a position similar to where Google and Apple are for phones. I.e., where they own the platform and can profit off of that.
And in what way are they then selling that data (which is what the person I replied to talked about)? Just the fact that the data is being sent to a server doesn't mean much. Tons of modern products relies on literally recording your data and sending it off to a server.
That's true - their revenue from VR/MR hardware is less than 2.5% of revenue though. Meanwhile, ads make up the other 97.5% of their revenue. 97.5% of everything Meta does is to hoover the data and sell it. It's effectively their entire business, while VR/MR stuff is a little side project.
That's true, but then, I'm not saying that the Quest is an offline-only device without cloud features. I'm saying that Meta didn't invest $63 billion just to create a "suction pipe for hoovering up that data". They have much bigger ambitions than that.
If they have other ambitions, those ambitions haven't materialised yet. Selling decent hardware at a loss and profiting from hoovering up user data is all Facebook has accomplished with the Quest so far from what I can see.
> You'd need proportional representation or something like the French system or you wind up with very skewed results
Is the French system a good example of a multi-party system? It currently seems to be struggling with handling three parties and it doesn't guarantee proportional representation. The presidential election is a winner-takes-all system and in the election for the Assemblée Nationale each constituency is a winner-takes-all.
> Is the French system a good example of a multi-party system?
I would say yes in the sense a new party can (and did) emerge and rise to power when there is demand. Even before that you had some healthy rise and fall of political parties and political alternance beyond just two main contenders.
> It currently seems to be struggling with handling three parties
There are like 6 parties with more than 10% of seats, the current government is a coalition of five parties (from two main "families") and no shutdowns or hung parliament.
> Doesn't guarantee proportional representation
That however is true, and by design. This is a property the french voting system share with eg: ranked choice and other systems that aim at resolving the compromise as part of the election rather than afterwards.
I don't mean to say that the french voting system is perfect (I quite like ranked choice), simply that it is a functioning one with interesting properties.
Thanks. I had no idea there where that many parties in the parliament. At the last election I got the impression that it was just Le Pen's party, Macron's party, and a left-wing coalition. But I guess that was simplifying media coverage.
Technically all of the main three blocs were coalitions, the bigger picture matching your description.
The left-wing coalition was about 9~10 parties, Macron's coalition was around 6~7 right leaning/centrist parties, and Le Pen's block joined by one or two smaller far right/conservative parties.
not necessarily, I just wanted to give an example of the kind of measures that would be required to handle multiple parties that people might already know.
