giomasce

No, Wine is not a container. The Windows application is free to make any Linux syscall with the privileges of the user running Wine. You shouldn't run an untrusted application in Wine any more than you would do for regular Linux applications.

Probably somebody on the wrong half, given that they didn't reply.

/s

> I can take a website seriously if they don't bother to remove placeholder text from their 'About Us'

Same here. I met a lot of people who were doing excellent jobs in what they did even if their presentation and marketing was not at the same level.

CEO of Nvidia: no need for coding anymore.

Me: considering how often your driver crashes, you still need coding.

How does an eSIM work? Does it require any special hardware (beside the cellular radio, of course) on the phone or is it a purely software thing? If there is specialized hardware, is it a thing that can be later deconfigured/uninstalled or does it modify permanently my device?

I would assume not, but this FAQ feels weird: "Unlike traditional removable SIM cards, eSIMs are built into devices during manufacturing and cannot be physically removed or replaced by users".

I can't know what they're doing, but it doesn't look like they're giving the lender any voting right. They're just borrowing some money and returning them in the following years. And I still can't see why this imply that the likelihood of the company failing is high.

They were already selling expensive seafood before, presumably with profit, why should that have changed? I imagine for a few years part or all of their profit will go to the lender while the pay back the loan. Then it's all for them again, except they're now owned by the trust instead of by the previous shareholders.

The point of having a trust is not to form capital, but to enforce a certain company governance system (as described in the legal documents with whom the trust is set up) without tying it to who happens to be the owner at any given moment.

Making profit is always a goal you achieve while doing something else: selling local seafood, writing software, designing chips, mining ores, whatever. So making profits and doing something else cannot be harder than just making profits. Also, companies receive and pay back loans all the time, it's quite a common procedure. Why should it be any different here?

Yes, leveraging Rosetta 2. Most programs should work, some might have caveats.

Really? They don't have anything better to do? What a poor career choice! In my naivety I had assumed that an exec's job was to help a company run smooth, and instead they have to sit through meetings all day long. Life is really hard on some people...

/s

I'd rather solve this problem by organizing the work day so that it's not meetings all day long, rather than requiring people to go to the office to waste time in presence.

Vulkan? Are you sure? Last time I checked it was just only Direct 3D. For Vulkan there is only MoltenVK.

The logo made the play, if possible, even more explicit: https://en.wikipedia.org/wiki/Back_Orifice.

That's not convincing: such a technique could still be in use since quite long for less sensitive targets; or it could be used by less "responsible" actors. Again, it doesn't look like the kind of stuff that you need to be the CIA to do.

Honestly I've been wondering for years why this is not already happening routinely. Not that I hope it, but I would say that even right now move a small bomb on a drone and letting it explode close to a random target should be quite easy for lightly organized movements, let alone modern armies. Why is so hard for the US to launch a horde of exploding drones towards Putin at the next time he sets foot outside of a building? Or for Russia to do the same for Biden?

Again, I don't hope that's our future, I just cannot understand why it's not our present already.

Even if they take the stance that Linux is a terrible thing, forcing terrible things on their users is hardly a new practice for Microsoft.

They should write something like "25% less fat in this package!".

If it had to deal with BCD it was a hell indeed...

That doesn't really align with the number of redistributable installers and "DLL not found" errors I've had to deal with during my Windows life. My wife's Win 10 system always boots to a "some DLL not found" fatal message, but after clicking OK everything seems to work as intended. I can't say I trust the way that system is set up.

Nice project, very cool!

A little note about section "Wine's implementation": the implementation described in Ken's email was never really used in Wine, intentionally (in vanilla Wine that kind of hack is not accepted). It has been used for a few years in CrossOver, CodeWeavers' fork of Wine (more recently also used by Apple for its Gaming Toolkit). Wine is currently moving towards supporting x86-on-ARM emulation properly by better separating the guest and host code, in a manner similar to how Windows itself does the same thing.

EDIT: Another quick thought: in the project readme you mention the observation that "win32 is the stable Linux userland ABI". The origin of that remark might have been this blog post by Arek Hiler: https://blog.hiler.eu/win32-the-only-stable-abi/.

I heard that the total wind power across the whole world is something like 20 times the total power humanity needs. So if we ended up doing this, we'd stealing some 5% of power from the wind, which is quite a lot. This itself could have significant climate consequences.

Solar shouldn't have this problem, instead: the amount of power we receive from the sun is ridiculously larger than what we can ever thing to consume.

I wonder why AMD decided to name chips after Italian cities...

I think she even looked into that at some point. But I don't think anything really happened.

Some years ago my aunt had sewn a vest that a zipper that converted it into an actual bag. Even when in the vest configuration, it was double, so it essentially was one single big pocket. You could stuff tons of things inside, and given that you could convert it into a bag it was also relatively convenient. You would keep it as a vest when having to prove that you would't carry other bags than allowed, and back to a bag at all other times (including during the security check).

So it should never do function inlining, or replace multiplication by two with a bit shift? Because both of them quite fit "invisibly modifying non-dead code during translation".

> or it could do what you fracking told it to, consequences be damned

Yes, that's precisely what happens. The point is agreeing on what you "told it". The agreement stipulated in the standard is that in some cases (when you hit UB) you're effectively not agreeing on anything, i.e., the compiler can do what it want.

If that's not what you like, please let me know what should be mandated in the case of the fragment I wrote above, and how a compiler could offer that guarantee in an efficient and effective manner.

So, which behaviours should be allowed for this code?

    void (*f)() = (void (*)())rand();
    f();

Is that because AMD GPUs are technically inferior for ML, or because of tooling is only written for NVIDIA?

I guess the advantage of passing ownership to the trust is that you're not involved anymore. If you keep shares you know that at some point in your life (or at the end of your life) you'll have to pass those to somebody else or setup a trust. Finding somebody else is hard, because it must be somebody that simultanously you trust deeply and who is willing to take on the responsibility to keep aligned with whatever way you want to company to be managed. So you setup a trust instead. Well, if you setup a trust immediately you don't have to think about that any more!

In principle they are somewhat similar: they're both Wine + local patches (either backported from more recent Wine versions or hacks that are not suitable for upstream Wine) + some glue. CrossOver also has a GUI, which Proton doesn't need because the GUI there is Steam and Proton is supposed to be as transparent as possible. And like I said for Proton, it's in our best interest to keep the diff between Wine and CrossOver as small as possible, because that's a liability that takes its toll at each rebase.

In practice Proton and CrossOver tends to have rather different sets of needs. Proton only supports Linux and is only focused on gaming. CrossOver exists for a handful of platforms, most notably macOS (which has a number of intricacies: missing 32 bit libraries, Apple Silicon, missing Vulkan drivers which requires MoltenVK, but MoltenVK itself cannot really offer all the features standard Vulkan drivers have on Linux), and is also used for non-gaming applications. CrossOver also lives in the form of specialized branches we develop for specific applications, on request of their developers. So while of course we share everything that can be shared, in my experience this tends to be not that much (except what goes upstream, of course). In pratice CrossOver and Proton live in different repositories, have independent build systems and independent release schedules.

On the technical level it should be totally doable. Whether that's something Valve is interested into, I don't have any privileged information.

I know people use CrossOver with Steam on macOS, though that requires a rather intricate setup I don't know much about. I guess what you'd like to have is the kind of seamless integration that Proton has with Steam on Linux.