They hide the knobs that would endear them with the tech community, source is not prominent/shared, and you can't subscribe to the serice using existing hardware.
For the average tech user concerned about privacy this may be a good deal, but to actually get SSL securely you need to manage your own domain and control your own certificates, otherwise the domain or certificate manager can be coerced by three-letter agencies to MITM your email. Additionally I see no allowance for hardware failure, if grandma and gramps lose 100GB or photos of their grand-kids, someone is going to be peeved. The subscription needs to include secure backups (anything where the service manages keys is not as secure as their average customer expects they are getting, and making people manage their keys themselves is bound to incur data loss and recovery failure). The only way out of the mess is a cryptographic secured ID system.
And letting the government do it is bound to incur abuse. I see two solutions, everybody use the Estonian E-citizenship and ID and pump enough value into the system that they don't dare subvert it. Or recognize ICANN as a sovereign entity like the red cross or knights of malta, and have them run a digital ID system.
As it stands now nobody on the kernel team wants it to go down in flames, but if the CCoC is enforced to the point we're a dev loses commit privileged because some anonymous SJW overheard that dev tell a slightly off-color joke at a conference, then there may very well be enough angry and put-off ex-devs that want to tear the whole project down.
But contributors don't gift the copyrighted code to the Linus Foundation, they merely license it. You can tell a street musician that he can play on your porch, and then tell him to get lost a week later when you're tired of his performance.
It's not on hardware yet, they're still working on securing patents. Toolchain based on LLVM is almost alpha, and they may or may not have started putting it onto an FPGA. They still are active and giving a talk at a conference this week.
BIOS/VGA are pretty damn standard at this point, Most of the bootable games aren't trying to do 3-D AAA style, but retro 2-D style. And even if hardware moves beyond that, there's alwasy QEMU.
The re-order is fairly static/deterministic on x86 on the instruction stream level. Yes there's some dynamism to make up for cache misses and mis-predicts, but that's about 20% of the performance gain. However the re-order logic takes up a lot of die space and power in the critical pathway. Additionally x86 can't be a VLIW machine, it has a really hard time dispatching 4 ops/cycle, whereas static in-order machines can dispatch many more ops. The 32nm Itaniums could do 6-12 ops/cyle. The Mill is designed to sustain 33 ops/second at the high end of the familiy. Whether a compiler can actually find that in the code is a different question. Itanium was a decent architecture even if a commercial flop between delays, compiler problems, and x86_64. I think the Mill may get it's foot in the door not by competing head to head with Xeons in conventional servers, but by being lower power HPC, and be being well-matched for the micro-kernel space. Strong hardware memory and process isolation combined with 3 cycle function calls (including interupts, and calls across permission boundries.) could effectively solve the IPC penalty on mainstream processors.
Right anymore the CISC target is an abstraction, that lets the decode unit in the chip one last chance at optimization before sending data to the computational assemblies. 80% of the out-of-order speed advantage comes better static schedules on chip. And most of the circuitry on a modern chip is dedicated to figuring out what to do next and getting ready to do it, vs actual silicon dedicated to is. Something like a VLIW can get a lot more performance/watt by letting the compiler do the scheduling and set-up, at the penalty of being poor at branch heavy code.
Of course it's text, what else would we use. Written languages are like 5,000 years old and have always been more expressive than pointing and gesturing.
Sure there are a few visual programming suites, but they are best suited for stream processing, and not for heavily branched general purpose code.
And a brain interface is a much harder problem, and trusting AI to write code could have devastating results.
Are you familiar with the proposed Mill architecture? Thier work with what they call turfs and portals sound very similar. It allows secure calls accross protection boundries, hardware managed data stacks, unforgeble process ID's, and byte-level permission granularity. It's definately not a RISC machine, but it's not a C machine either with hardware features that treat pointers as type of thier own which contain hardware managed meta-data bits usefull to accelerate garbage collection.
No, Out of the Box Computing wants to be a chip manufacturer, and the fallback is the be an IP house like ARM. And the design is as a family, so I don't think it would be hard to find a chip to run a tablet or phone with a secure micro-kernel. And yes that is the great befifit of the chip, and they make function calls about as cheap as any architecture while providing a secure hardware-managed stack.
The apps like Scratch with visual blocks, animations and hand holding, will introduce basic concepts, but it doesn't let you affect anything outside the app, which is boring at a certain point. And we're not taking kids, we're talking students, which could be 16,17,18 and potentially quite capable of going beyond the basics.
To get the iOS dev kit, it's $99/year, the SDK runs only on iMac hardware, and you can only load the resulting software on phones you own unless you get approval to load it on the app store. It's totally ridiculous and crippled even compared to a cheap single-board computer running debian.
In terms of productivity, a keyboard is a minimum requirement. It's also very hard to develop for a phone with a phone, much less the ability to change anything meaningful about the operation of the device. Architecturally there's little difference between a smartphone and a desktop, behaviorally there's a vast difference.
AMD avoided some of it by forcing separate page tables to be used for different permission rings, user code being speculated couldn't access kernel memory, because it had no clue what the physical address actually was.
Speculation doesn't reduce the amount of time needed to run code, it reduces the amount of time the processor is idle by letting you run out-of-order across branch instructions. The problem isn't in running out of order, it's running instructions before permissions are checked and not unwinding every side effect. Intel didn't do it because direct access to those effects still isn't allowed, and doing a proper unwind would increase the branch misdirect penalty, or significantly complicate the instruction pipeline.Speculation can be done without these flaws, it just gets less cost effective to do so. I do hope the mill architecture makes an appearance soon, as high-performance and low-power for general purpose code without speculation would be nice.
The theory requires you to eliminate side effects to be secure, but to speculate to any depth of calculaton you need access to intermediary results (e.i side effects). The implementation didn't suck, it was a very good implementation, but speculation at its core has a strong rellelence to security. To actually do it securely you need a lot of setup, adding costs to context switches, or you need to to design the pipeline to guarantee an undo on failed speculation including undoing the side effects such as cache loads and evictions.
Simplifying and cutting regulations is generally a good thing, which can even result in a clearer standard that is easier to enforce and the whole college model is due for a shake-up. However Trump "university" is so far from an accredited program you'd have to cut 95% of the regulations to accredit it, in which case states and colleges would pursue a parallel accreditation program that actually meant something.
If the target is using end to end ecryption, get a F'ing warrant and hack the endpoint(s), assign tail teams... Mass surveillance does not protect the "citizens", and enables a government of the state, by the state, for the state, doing material harm to everyone on the planet.
Slashdot Mirror
They hide the knobs that would endear them with the tech community, source is not prominent/shared, and you can't subscribe to the serice using existing hardware.
For the average tech user concerned about privacy this may be a good deal, but to actually get SSL securely you need to manage your own domain and control your own certificates, otherwise the domain or certificate manager can be coerced by three-letter agencies to MITM your email. Additionally I see no allowance for hardware failure, if grandma and gramps lose 100GB or photos of their grand-kids, someone is going to be peeved. The subscription needs to include secure backups (anything where the service manages keys is not as secure as their average customer expects they are getting, and making people manage their keys themselves is bound to incur data loss and recovery failure). The only way out of the mess is a cryptographic secured ID system.
And letting the government do it is bound to incur abuse. I see two solutions, everybody use the Estonian E-citizenship and ID and pump enough value into the system that they don't dare subvert it. Or recognize ICANN as a sovereign entity like the red cross or knights of malta, and have them run a digital ID system.
As it stands now nobody on the kernel team wants it to go down in flames, but if the CCoC is enforced to the point we're a dev loses commit privileged because some anonymous SJW overheard that dev tell a slightly off-color joke at a conference, then there may very well be enough angry and put-off ex-devs that want to tear the whole project down.
But contributors don't gift the copyrighted code to the Linus Foundation, they merely license it. You can tell a street musician that he can play on your porch, and then tell him to get lost a week later when you're tired of his performance.
How well is it spread out over threads?
It's not on hardware yet, they're still working on securing patents. Toolchain based on LLVM is almost alpha, and they may or may not have started putting it onto an FPGA. They still are active and giving a talk at a conference this week.
Also the lead designer of Itanium died before it was brought to market and the vision was compromised as a result.
BIOS/VGA are pretty damn standard at this point, Most of the bootable games aren't trying to do 3-D AAA style, but retro 2-D style. And even if hardware moves beyond that, there's alwasy QEMU.
The re-order is fairly static/deterministic on x86 on the instruction stream level. Yes there's some dynamism to make up for cache misses and mis-predicts, but that's about 20% of the performance gain. However the re-order logic takes up a lot of die space and power in the critical pathway. Additionally x86 can't be a VLIW machine, it has a really hard time dispatching 4 ops/cycle, whereas static in-order machines can dispatch many more ops. The 32nm Itaniums could do 6-12 ops/cyle. The Mill is designed to sustain 33 ops/second at the high end of the familiy. Whether a compiler can actually find that in the code is a different question. Itanium was a decent architecture even if a commercial flop between delays, compiler problems, and x86_64. I think the Mill may get it's foot in the door not by competing head to head with Xeons in conventional servers, but by being lower power HPC, and be being well-matched for the micro-kernel space. Strong hardware memory and process isolation combined with 3 cycle function calls (including interupts, and calls across permission boundries.) could effectively solve the IPC penalty on mainstream processors.
Right anymore the CISC target is an abstraction, that lets the decode unit in the chip one last chance at optimization before sending data to the computational assemblies. 80% of the out-of-order speed advantage comes better static schedules on chip. And most of the circuitry on a modern chip is dedicated to figuring out what to do next and getting ready to do it, vs actual silicon dedicated to is. Something like a VLIW can get a lot more performance/watt by letting the compiler do the scheduling and set-up, at the penalty of being poor at branch heavy code.
Of course it's text, what else would we use. Written languages are like 5,000 years old and have always been more expressive than pointing and gesturing.
Sure there are a few visual programming suites, but they are best suited for stream processing, and not for heavily branched general purpose code.
And a brain interface is a much harder problem, and trusting AI to write code could have devastating results.
Are you familiar with the proposed Mill architecture? Thier work with what they call turfs and portals sound very similar. It allows secure calls accross protection boundries, hardware managed data stacks, unforgeble process ID's, and byte-level permission granularity. It's definately not a RISC machine, but it's not a C machine either with hardware features that treat pointers as type of thier own which contain hardware managed meta-data bits usefull to accelerate garbage collection.
Mainly because CPU's have gotten so efficient that RAM power usage has a noticeable affect on battery life.
No, Out of the Box Computing wants to be a chip manufacturer, and the fallback is the be an IP house like ARM. And the design is as a family, so I don't think it would be hard to find a chip to run a tablet or phone with a secure micro-kernel. And yes that is the great befifit of the chip, and they make function calls about as cheap as any architecture while providing a secure hardware-managed stack.
The apps like Scratch with visual blocks, animations and hand holding, will introduce basic concepts, but it doesn't let you affect anything outside the app, which is boring at a certain point. And we're not taking kids, we're talking students, which could be 16,17,18 and potentially quite capable of going beyond the basics.
But you have to pay it all up front for a chromebook. You can get an iPhone for $45/month for 18 months.
To get the iOS dev kit, it's $99/year, the SDK runs only on iMac hardware, and you can only load the resulting software on phones you own unless you get approval to load it on the app store. It's totally ridiculous and crippled even compared to a cheap single-board computer running debian.
In terms of productivity, a keyboard is a minimum requirement. It's also very hard to develop for a phone with a phone, much less the ability to change anything meaningful about the operation of the device. Architecturally there's little difference between a smartphone and a desktop, behaviorally there's a vast difference.
You need the SEV instruction/extensions specifically.
AMD avoided some of it by forcing separate page tables to be used for different permission rings, user code being speculated couldn't access kernel memory, because it had no clue what the physical address actually was.
Speculation doesn't reduce the amount of time needed to run code, it reduces the amount of time the processor is idle by letting you run out-of-order across branch instructions. The problem isn't in running out of order, it's running instructions before permissions are checked and not unwinding every side effect. Intel didn't do it because direct access to those effects still isn't allowed, and doing a proper unwind would increase the branch misdirect penalty, or significantly complicate the instruction pipeline.Speculation can be done without these flaws, it just gets less cost effective to do so. I do hope the mill architecture makes an appearance soon, as high-performance and low-power for general purpose code without speculation would be nice.
The theory requires you to eliminate side effects to be secure, but to speculate to any depth of calculaton you need access to intermediary results (e.i side effects). The implementation didn't suck, it was a very good implementation, but speculation at its core has a strong rellelence to security. To actually do it securely you need a lot of setup, adding costs to context switches, or you need to to design the pipeline to guarantee an undo on failed speculation including undoing the side effects such as cache loads and evictions.
But it's receive only, not really useful for a communication device.
Simplifying and cutting regulations is generally a good thing, which can even result in a clearer standard that is easier to enforce and the whole college model is due for a shake-up. However Trump "university" is so far from an accredited program you'd have to cut 95% of the regulations to accredit it, in which case states and colleges would pursue a parallel accreditation program that actually meant something.
"Hey that's an awfully neat tax avoidance scheme you have there, it'd be a shame is something happened to it"
If the target is using end to end ecryption, get a F'ing warrant and hack the endpoint(s), assign tail teams... Mass surveillance does not protect the "citizens", and enables a government of the state, by the state, for the state, doing material harm to everyone on the planet.