Search results

After a quick check, mesa's newest built-in software rasterizer, llvmpipe, seems to be pretty efficient. However, it looks like it doesn't support ARM assembly.

Doesn't it use UPnP or something similar ?

I guess somebody is spending some time in Syden :p

Afaik, the adapter isn't proprietary, it is custom. It also doesn't have any kind of logic.

I didn't find any noteworthy documentation, but it looks like Maru OS is just Android with a (well configured) Debian chroot and the chroot outputs its graphics output towards HDMI. I might be wrong. (I didn't spend too much time on it)

Does that mean the Pyra won't support DRM (Direct Rendering Manager) ? I'm not an expert, but as far as I understand fbdev seems to pose certain problems which DRM solved.

As far as I know, having more RAM would have a positive impact in one case : Disk access caching. The RAM should still be faster than any available storage. However, one would need a very specific use case to really see a lot of improvement. My laptop has 4 GB of RAM and is configured to save...

I doubt that the switch would take that long. We're not talking about a relay or similar.

An additional proof that systemd is well designed :P

Well, the question is, what is "home". Is it somebody else's or my own machine ?

As far as I remember, the only problem would be that the OS (read: The Linux kernel) has to be 64-bit. That's it. Since only a minority of the Pyra specific code would be ARMv7-A specific, it shouldn't be a problem. On an application level, ARMv8-A is totally compatible with previous versions.

I think that's because your profile doesn't say "Moderator" or "Staff Member" :P

As far as I understand it, it totally would be able to. It might be more or less efficient than a conventional computer (QC is not going to revolutionize the world of spreadsheets ...), but it shouldn't be impossible. The problem with OTP is that if you intercept an encrypted text, trying out...

That's called one-time pad and doesn't work with public-key crypto. If there is a public-key crypto that can't be (theoretically easily) broken by QC, I would like to know myself.

I know, that's why I used an exclamation mark.

Basically, QC is able to solve most crypto problems that don't use a bijection from the origin set into the target set (or in general sets of the same size).

Why doing licensing from ARM ? Just hire hns to design a full SoC from scratch !

I see two logical fallacies. First, the fact that anyone spend any amount of time on any task doesn't give it any value. Just because I spent "countless hours" drawing something doesn't mean that the result will be good. Then, you do not tell us (or even link to) the merits of the DBP system...

Actually, how much can the DBP format do that AppImage can't ? How much is due to the daemon ?

Well, you still need a script system to create the packages.