Earlier quoted context omitted.
How?
You just have one. https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
So you still have two, at least with Gnome 3 on Wayland.
221–230 of 236 posts
Earlier quoted context omitted.
How?
You just have one. https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
So you still have two, at least with Gnome 3 on Wayland.
I'm interested in the possibility of eventually having FPGA-driven systems where you can load up an ISA and use that. Imagine if every week you could expect an ISA architecture update that came with a power usage or speed improvement.
The problem is that no FPGA-driven system will come close to beating out a modern CPU, so people will have very little incentive to actually use it because it will probably be more expensive and definitely slower.
The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…
I'd pay good money for an open and simpler platform to run my security-critical tasks that don't require top performance. Auditing a modern high-end CPU is probably a huge task even if you have access to the HDL because of how complex they are. A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web, send emails a…
Earlier quoted context omitted.
The approach is helpful, perhaps not very practical (do I maintain N different browser installations in my qube for N different tasks, or is it a single installation where malware can therefore affect all qubes?). But remember that OS and libraries have plenty of bugs too.
I suppose that an OS running transparently on an actual cluster of many independent cores, not linked even by a common L2 cache, could allow to separate security domains much more reliably. Single-thread performance would suffer, though, unless you're ready to pay quite a lot. And it's still hugely important in many cases.
The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…
I'd pay good money for an open and simpler platform to run my security-critical tasks that don't require top performance. Auditing a modern high-end CPU is probably a huge task even if you have access to the HDL because of how complex they are. A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web, send emails a…
Earlier quoted context omitted.
> instead of keeping their optimizations proprietary There were no magic secret optimizations to release. It just straight up did not work. They had to add back dynamic branch prediction, and even then the load store latency was such trash that they had to put ginormous L3 caches on it to get even close to reasonable performance.
That's fair. I have never worked with them, so I don't know the precise details; but one of the big complaints I've heard was that compilers weren't ready for them yet, while these days there's now a larger field of open source compilers and has been a lot more research in parallelism.
Yeah, compilers today are no better. We found the limits of statically scheduled parallelism pretty fast. On code that uses static scheduling, a modern OoO processor can easily duplicate what IA64 was capable of (and a pipelined loop using AVX will utterly smoke it), while being far better at all the stuff IA64 failed at.
The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore o…
> Open isn't a magic bullet. > more about quality of auditing. Exactly. Being open makes things easier to audit, and to an extent encourages better due diligence (as embarrassments due to silly mistakes or, worse, attempted cover-ups, are more public!), but it doesn't enforce this in any way nor does it guarantee quality or completeness.
...and if I in fact identify any shortcomings, I can help others not to get hit by them, which makes the concept of openness "safer" in a way that is the sum of collective knowledge.
Earlier quoted context omitted.
> Open isn't a magic bullet. > more about quality of auditing. Exactly. Being open makes things easier to audit, and to an extent encourages better due diligence (as embarrassments due to silly mistakes or, worse, attempted cover-ups, are more public!), but it doesn't enforce this in any way nor does it guarantee quality or completeness.
The point here should be about responsibility. When I screw up something that I picked up from "out in the open", eg. my server deployments, it more technically makes it my own fault. I am therefore more inclined to study an open circuit design because if it fails on me, I'm only left with myself to blame. ...and if I in fact identify any shortcomings, I can help others not to get hit by them, which makes the concept…
I'd actually love to see a bazaar on the cpu side of things, be it just for the sake of what community efforts can achieve as opposed to the current mostly proprietary ecosystem.
understanding the electricity and visualizing the magnetism and diverse waves and its interactivities; in order to detect as to the example of a bird landing on the high voltage wires and how the properties of the particles can be read as well as stored in plants etc. and how the materials are properly constructed in order to distort the assimilation necessary to start the machine ;
and then destroy the school logic as to algebra titles etc, in which it is part after the experiments to start organizing circuit logic; maybe something about the quality of the electricity by improving the components including rust and dusting etc. perhaps thus by sealing the components in the process of initializing the machine to verify the veracity of the circuits; some degree of upgradeable serial number in order to connect other parts, perhaps identifying a first problem of logic; - and perhaps the idealization of unique components like the Raspberry system-board? where volatile parts is taken as user Hard-Disk content being the logic of software?
so better focusing on the complexity required than the ultra-fast Quantum Computer processor? can be produced at higher levels for virtual realities; [?] Just Guess;
Earlier quoted context omitted.
You're giving up on a ton of performance by dropping OoOE. In particular, you end up losing the ability to avoid stalling on cache misses, and the memory wall becomes an increasingly gigantic problem even as Moore's Law progresses.
Hyper-threading helps with that.