I think the article should say "[W]hat's so compelling about RISC-V isn't just the technology".
The instruction set is modern and tight, made to be easy to pipeline and scale. There are RISC-V chips that rival ARM in performance / watt at the same manufacturing process. The ISA is modular so engineers could strip out the parts they don't need and get more power savings that way.
But I would not say that it is mature yet. There are important parts, such as the memory consistency model that I have not yet seen set in stone.
ARM cores with out-of-order execution are vulnerable to (regular) Spectre where as most ARM cores with in-order execution are not. ARM posted a list of which that are affected. (But they use their own nomenclature...)
ARM Cortex-A53 and Cortex-A55 are the fastest 64-bit ARM cores without speculative execution, and yes, I think you'd want to choose 64-bit ARM (AArch64) for new applications. Cortex-A53 is a bit old and most easily found in the Raspberry Pi 3 Model B and 3 Model B+ single-board computers, with four cores each. Both SBCs are cheap, widely available and have a lot of support. The Model B+ runs cooler and faster (1.4 GHz) than the Model B but both need heat sinks. If a heat sink is included at all in a kit it is often too small to be able to allow the chip to run at full speed for any length of time.
The Cortex-A55 is touted as being 20% faster than the A53 per clock. Most SoCs with the Cortex-A55 are running in a big.LITTLE configuration together with faster cores that run out-of-order. I have found only one SoC with only A55: the Spreadtrum SC9863, which has eight cores at up to 1.6 GHz. It was announced in May and it is so early that I can't even find a datasheet for it. Please do comment if you know of another option.
That was my first thought as well, but those devices are already out there. In the Galaxy Note 7 fiasco we saw not only that even mainstream manufacturers could make defective devices but also that a large number of users don't turn their devices in despite of the dangers being widely publicised.
What Google is doing (now) is about "damage control": limiting the extent of the damage.
What ELFbac is doing is to partition the memory space into regions with different protection depending on which region the access is coming from. You could say that it is like automated partitioning of a program into multiple processes communicating via shared memory.
The cool feature here is that the access control matrix is derived from the existing link information in the binary itself (ELF format), which means that no code rewrite is necessary.
I'm not sure how it would stop Spectre though, especially on Intel which runs code speculatively before access control. I'm looking forward to reading the paper (especially since I'm already drawing ideas from it to another project...)
(7) No close button should ever be visible unless you hover over it. If you happen to use a pen or touch (for instance a MS Surface "laptop"), then controls should either close when you tap blank space or never be able to be closed at all. Mouse users should just be annoyed, and lose history and data after close buttons have suddenly appeared.
If the burrowing beetle is "the bane of oil companies", then why don't we breed more burrowing beetles? That could become an effective method to fight global warming, now, wouldn't it?
No, seriously. Do proofread and edit submissions before posting! Don't just copy and paste.
Not necessarily. By the edges of the tabs being diagonal they can be closer to the tab label without looking cluttered, but a trapezoidal tab shape is more distinguishable than a rectangle.
This is actually several months old news. From earlier screenshots of the previous and new look of Chrome tabs, it has been have shown that tab labels are precisely the same distance apart. The "new" square look uses more vertical pixels though.
Systems such as containers, pledge, seccomp, jails, systrace variants, chroot etc. are all about restricting what otherwise would have been a process's ambient authority by plugging holes here and there until you can't find any more holes to plug. The problem is the holes that you don't find.
Another approach is to do the opposite: start with the process having no authority and give it only explicit access to the specific interfaces of the specific objects it needs to do its job --- and nothing more. That is called Capability-based security and is IMHO the only fail-safe way to sandbox processes. Some of Unix's predecessors had capabilities, some even with special CPU support so that it did not hav emore overhead than shifting pointers, but it was one of those many things that were not included when the original Unix was written to work on off-the-shelf hardware.
In recent years, a capabilities model has been added to BSDs and Linux in the form of the Capsicum project. The other day, I stumbled over the CloudABI system, which is a runtime environment that uses Capsicum for applications on cloud servers. With CloudABI your applications would be sandboxed just as safely as if they ran on virtual machines but without the overhead.
The big drawback is that programs need to be rewritten for it. The idea is though that when rewriting a program for CloudABI you should mostly just have to change things to make it compile and run. This would entail quite a bit of gruntwork but it should be pretty much straightforward and therefore less error-prone than to tweak security policies for something like seccomp or SELinux.
And BTW, chroot was never intended to be used for sandboxing.
That is why Microsoft licensed MagSafe tech from Apple for their Surface line.
There are also third-party magnetic adapters for USB and Lightning that turn the connectors into magnetic connectors. However, I believe that magnetic adapters for USB Type C support only slow charging and slow speed over the USB 2.0 subset, making them not suitable for charging laptops.
I think there is a point in breeding crops the slow traditional way over several generations (of crops): You notice the faults with a breed of crop over some time, and you often have a larger number of different seeds to use for the next generation. Of course you could do gene editing in a responsible, slow way too, but it gene editing is being sold on its speed and instant results.
A clone is not technically a hard link, but it works similarly: The disk blocks storing the data are not affected, only references to them. However, unlike with links, a disk block could get copied as soon as you would to write to a file. Thus, cloning retains the same semantics as copying --- actual copying is only deferred until it is really needed. This technique is classically called "copy-on-write" and is employed in lots of different ways in many different parts of mainstream operating systems.
BTW. Btrfs for Linux also has cloning, and it was released eight years earlier than APFS. Sun's/Oracle's ZFS has cloning and was released earlier than that. I think there are many more examples in the free software world than those two.
Meanwhile, Denmark has its "båndkopi" (tape copy) fee on practically all storage media -- whether it is being used for music or not -- to compensate for copying. The collected money is distributed to a select number of rights holders through some scheme by the industry organisation Copydan.
The "båndkopi" fee was created once upon a time because the music industry complained that people could copy music to tapes from records and the radio... And now that Youtube and other streaming services are basically serving the same function that radio did, things are different?
How much light you have on a day depends on how close to a pole you live, and if it is summer or winter. Judging from your username I suppose you are in Southern USA. Well, southern Europe is about as far north as northern USA.
For me in Stockholm in Northern Europe, the sun sets today at 10 pm and rises at 03:47 am CET. One hour forwards or backwards would not matter because it is TOO BRIGHT anyway.
BTW, in the middle of winter, if the day is cloudy it may only get as bright as the summer nights are darkest. But then we don't have DST.
Thanks! I needed a good laugh today, to get my mind off my own mistakes. However much you have effed up yourself, there is always a bigger idiot who did something bigger.
It still lacks a real middle button. They could have added a real button instead of the weird bump before the scroll wheel.
It is too difficult to not scroll by mistake when trying to press down the wheel. I mean, you can press accurately 95% of the time, but each of those of the 5% mis-clicks are errors that you should never have made.
No, the phones are usually running ARM cores in big.LITTLE configuration where only half of the cores are actually powered at the same time. Half of the cores are slow but don't draw too much battery. The other half are high-performance cores (wider issue, out-of order and/or higher clock speed) that draw more power. The mobile phone industry is leading the development, and other applications such as TV boxes are picking up the leftovers that are no longer relevant for the most performing flagship phones -- and that is why you see these "eight core" SoC:s in TV boxes, where as low-performance power-saving cores would not be a requirement for them.
ARM's successor to "big.LITTLE" called "DynamIQ" has more options for configurations, no longer limited to cutting the cores in half. There are eight-core SoC:s in development where only one or two are high-performance cores and the rest are low-performance cores. On the plus side though, more cores may be available to run at once.
The i7-8086K is a 40 year anniversary of the 8086 CPU. 40 years of only incremental upgrades to a crap ISA. It is still what is holding the x86-64 platform back.
I can't wait for AArch64, or even RISC-V, to become mainstream.
The origin of 1 (noun and verb) is from "hack saw". The verb "hack" means literally to use the hack saw. It then was used to mean doing a simple ugly fix using the hack saw, a kludge,or a bodge.
Students at MIT were hacking and bodging things in the real world to commit practical pranks that modified something at the campus. These pranks (with hack saw or not) were called "hacks" and clever pranksters at MIT were called "hackers". Later such hackers from MIT were influential on early personal computing as we know it.
So, I would argue that the use of "life hack" to mean "bodging something in a clever but ugly way" is closer to the original meaning of the word than to mean breaking into a system.
BTW. Practical jokes have a long history at universities around the world and they are still called "hacks" over at MIT. The second noun use ("unqualified person") has a completely different etymology (origin of words) than the first and is not related but it does give the word a negative connotation in general doesn't it...
Not more drastic than what lifestyle has changed in the last thirty years. Greenhouse gas emissions are seriously higher now than they were in the '80s. The current generation eats more red meat than their parents. People fly more, drive more and consumer goods are produced in far-away countries with more lax emission laws and then they are shipped to the West by boats or planes running on oil. The diet of the current Western world is leading to more heart disease, which is a good reason to reduce consumption of red meat anyway. Production overseas costs jobs locally.
And you can't say that the average American or European had a low standard of living back in the 1980s.
At international conferences, there have indeed been a lot of squabble about how much "climate debt" the developed world has... as an argument from less developed countries to be be allowed to emit more greenhouse gases. None of that is productive, of course. We need to realise that it is too late for those kinds of demands. Instead we should focus on the cost: that countries closer to the equator -- which are often the poorer and the least developed, are going to be hit the hardest. We should be in "damage control" mode already!
Keep in mind that every action we do to affect emissions and the climate has a ~30-year delay before any effect can be measured.
Most current "flagship" phones use multicore CPUs in big.LITTLE configuration. In most of these the "big" part are cores with speculative execution, which are activated when there is a need for more power. Most exploits in the class that Spectre is in need to first prime the cache and speculator through code in long-running loops (and especially on ARM), which means that they would always be promoted to run on the "big" cores anyway.
I wrote "most phones" above, because some SoC:s, like Snapdragon 835 and 845 have only cores with speculative execution, the "little" cores being also speculative, only clocked lower. These are the cores most used in upcoming Windows 10/ARM laptops.
Indeed. Most current Microsoft tablets are neither functional tablets nor functional PCs but still crippled half-arsed compromises.
The devices need ports, to be able to receive power and forward power to a device that has a single USB lead. I often use a 8" Lenovo Yoga Tab with Windows 10. The hardware is pretty good except for having only one port. I want a proper OS on it that allows me to do file management. But Windows' user interface in "tablet mode" is half-assed, and would be completely unusable if the device in question did not support a pen to simulate a mouse. Then there is the issue of screen scaling. Windows 8 was released to developers in 2011 already. That's SEVEN YEARS in which they could have made it proper.
I think he meant homing nubs on the home row's keys. They are used to find the right hand position by touch alone. Look closely at the F and J keys on a physical keyboard!
I think a bigger issue though is that you can't use muscle memory from physical keyboards on touch screens. Physical keyboards have a very specific layout with each key allocated a 3/4" by 3/4" square and rows being offset 1/2 and 1/4 key. Even Apple's keyboards adhere to that standard (except slightly smaller on the vertical). Touch screen keyboards very rarely have keys exactly that size, size, shape and staggering. A touch screen would have to be at least 25 cm / 10" wide to fit a regular keyboard layout, which few do.
Slashdot Mirror
I think the article should say "[W]hat's so compelling about RISC-V isn't just the technology".
The instruction set is modern and tight, made to be easy to pipeline and scale. There are RISC-V chips that rival ARM in performance / watt at the same manufacturing process.
The ISA is modular so engineers could strip out the parts they don't need and get more power savings that way.
But I would not say that it is mature yet. There are important parts, such as the memory consistency model that I have not yet seen set in stone.
ARM cores with out-of-order execution are vulnerable to (regular) Spectre where as most ARM cores with in-order execution are not.
ARM posted a list of which that are affected. (But they use their own nomenclature...)
ARM Cortex-A53 and Cortex-A55 are the fastest 64-bit ARM cores without speculative execution, and yes, I think you'd want to choose 64-bit ARM (AArch64) for new applications.
Cortex-A53 is a bit old and most easily found in the Raspberry Pi 3 Model B and 3 Model B+ single-board computers, with four cores each. Both SBCs are cheap, widely available and have a lot of support. The Model B+ runs cooler and faster (1.4 GHz) than the Model B but both need heat sinks. If a heat sink is included at all in a kit it is often too small to be able to allow the chip to run at full speed for any length of time.
The Cortex-A55 is touted as being 20% faster than the A53 per clock. Most SoCs with the Cortex-A55 are running in a big.LITTLE configuration together with faster cores that run out-of-order.
I have found only one SoC with only A55: the Spreadtrum SC9863, which has eight cores at up to 1.6 GHz. It was announced in May and it is so early that I can't even find a datasheet for it.
Please do comment if you know of another option.
That was my first thought as well, but those devices are already out there.
In the Galaxy Note 7 fiasco we saw not only that even mainstream manufacturers could make defective devices but also that a large number of users don't turn their devices in despite of the dangers being widely publicised.
What Google is doing (now) is about "damage control": limiting the extent of the damage.
What ELFbac is doing is to partition the memory space into regions with different protection depending on which region the access is coming from.
You could say that it is like automated partitioning of a program into multiple processes communicating via shared memory.
The cool feature here is that the access control matrix is derived from the existing link information in the binary itself (ELF format), which means that no code rewrite is necessary.
I'm not sure how it would stop Spectre though, especially on Intel which runs code speculatively before access control. I'm looking forward to reading the paper (especially since I'm already drawing ideas from it to another project ...)
(7) No close button should ever be visible unless you hover over it.
If you happen to use a pen or touch (for instance a MS Surface "laptop"), then controls should either close when you tap blank space or never be able to be closed at all. Mouse users should just be annoyed, and lose history and data after close buttons have suddenly appeared.
If the burrowing beetle is "the bane of oil companies", then why don't we breed more burrowing beetles? That could become an effective method to fight global warming, now, wouldn't it?
No, seriously. Do proofread and edit submissions before posting!
Don't just copy and paste.
Not necessarily. By the edges of the tabs being diagonal they can be closer to the tab label without looking cluttered, but a trapezoidal tab shape is more distinguishable than a rectangle.
This is actually several months old news.
From earlier screenshots of the previous and new look of Chrome tabs, it has been have shown that tab labels are precisely the same distance apart. The "new" square look uses more vertical pixels though.
Systems such as containers, pledge, seccomp, jails, systrace variants, chroot etc. are all about restricting what otherwise would have been a process's ambient authority by plugging holes here and there until you can't find any more holes to plug. The problem is the holes that you don't find.
Another approach is to do the opposite: start with the process having no authority and give it only explicit access to the specific interfaces of the specific objects it needs to do its job --- and nothing more.
That is called Capability-based security and is IMHO the only fail-safe way to sandbox processes.
Some of Unix's predecessors had capabilities, some even with special CPU support so that it did not hav emore overhead than shifting pointers, but it was one of those many things that were not included when the original Unix was written to work on off-the-shelf hardware.
In recent years, a capabilities model has been added to BSDs and Linux in the form of the Capsicum project.
The other day, I stumbled over the CloudABI system, which is a runtime environment that uses Capsicum for applications on cloud servers.
With CloudABI your applications would be sandboxed just as safely as if they ran on virtual machines but without the overhead.
The big drawback is that programs need to be rewritten for it. The idea is though that when rewriting a program for CloudABI you should mostly just have to change things to make it compile and run. This would entail quite a bit of gruntwork but it should be pretty much straightforward and therefore less error-prone than to tweak security policies for something like seccomp or SELinux.
And BTW, chroot was never intended to be used for sandboxing.
That is why Microsoft licensed MagSafe tech from Apple for their Surface line.
There are also third-party magnetic adapters for USB and Lightning that turn the connectors into magnetic connectors.
However, I believe that magnetic adapters for USB Type C support only slow charging and slow speed over the USB 2.0 subset, making them not suitable for charging laptops.
I think there is a point in breeding crops the slow traditional way over several generations (of crops): You notice the faults with a breed of crop over some time, and you often have a larger number of different seeds to use for the next generation.
Of course you could do gene editing in a responsible, slow way too, but it gene editing is being sold on its speed and instant results.
A clone is not technically a hard link, but it works similarly: The disk blocks storing the data are not affected, only references to them.
However, unlike with links, a disk block could get copied as soon as you would to write to a file.
Thus, cloning retains the same semantics as copying --- actual copying is only deferred until it is really needed.
This technique is classically called "copy-on-write" and is employed in lots of different ways in many different parts of mainstream operating systems.
BTW. Btrfs for Linux also has cloning, and it was released eight years earlier than APFS. Sun's/Oracle's ZFS has cloning and was released earlier than that.
I think there are many more examples in the free software world than those two.
Meanwhile, Denmark has its "båndkopi" (tape copy) fee on practically all storage media -- whether it is being used for music or not -- to compensate for copying.
The collected money is distributed to a select number of rights holders through some scheme by the industry organisation Copydan.
The "båndkopi" fee was created once upon a time because the music industry complained that people could copy music to tapes from records and the radio ...
And now that Youtube and other streaming services are basically serving the same function that radio did, things are different?
How much light you have on a day depends on how close to a pole you live, and if it is summer or winter.
Judging from your username I suppose you are in Southern USA. Well, southern Europe is about as far north as northern USA.
For me in Stockholm in Northern Europe, the sun sets today at 10 pm and rises at 03:47 am CET. One hour forwards or backwards would not matter because it is TOO BRIGHT anyway.
BTW, in the middle of winter, if the day is cloudy it may only get as bright as the summer nights are darkest. But then we don't have DST.
Thanks! I needed a good laugh today, to get my mind off my own mistakes.
However much you have effed up yourself, there is always a bigger idiot who did something bigger.
It still lacks a real middle button. They could have added a real button instead of the weird bump before the scroll wheel.
It is too difficult to not scroll by mistake when trying to press down the wheel. I mean, you can press accurately 95% of the time, but each of those of the 5% mis-clicks are errors that you should never have made.
Then you overslept. Trackballs have been cool for a long time.
No, the phones are usually running ARM cores in big.LITTLE configuration where only half of the cores are actually powered at the same time.
Half of the cores are slow but don't draw too much battery. The other half are high-performance cores (wider issue, out-of order and/or higher clock speed) that draw more power.
The mobile phone industry is leading the development, and other applications such as TV boxes are picking up the leftovers that are no longer relevant for the most performing flagship phones -- and that is why you see these "eight core" SoC:s in TV boxes, where as low-performance power-saving cores would not be a requirement for them.
ARM's successor to "big.LITTLE" called "DynamIQ" has more options for configurations, no longer limited to cutting the cores in half. There are eight-core SoC:s in development where only one or two are high-performance cores and the rest are low-performance cores. On the plus side though, more cores may be available to run at once.
The i7-8086K is a 40 year anniversary of the 8086 CPU.
40 years of only incremental upgrades to a crap ISA. It is still what is holding the x86-64 platform back.
I can't wait for AArch64, or even RISC-V, to become mainstream.
(posted from a PC with an intel i7 :-P )
The origin of 1 (noun and verb) is from "hack saw". The verb "hack" means literally to use the hack saw. It then was used to mean doing a simple ugly fix using the hack saw, a kludge,or a bodge.
Students at MIT were hacking and bodging things in the real world to commit practical pranks that modified something at the campus.
These pranks (with hack saw or not) were called "hacks" and clever pranksters at MIT were called "hackers". Later such hackers from MIT were influential on early personal computing as we know it.
So, I would argue that the use of "life hack" to mean "bodging something in a clever but ugly way" is closer to the original meaning of the word than to mean breaking into a system.
BTW. Practical jokes have a long history at universities around the world and they are still called "hacks" over at MIT. ...
The second noun use ("unqualified person") has a completely different etymology (origin of words) than the first and is not related but it does give the word a negative connotation in general doesn't it
Not more drastic than what lifestyle has changed in the last thirty years.
Greenhouse gas emissions are seriously higher now than they were in the '80s.
The current generation eats more red meat than their parents. People fly more, drive more and consumer goods are produced in far-away countries with more lax emission laws and then they are shipped to the West by boats or planes running on oil.
The diet of the current Western world is leading to more heart disease, which is a good reason to reduce consumption of red meat anyway. Production overseas costs jobs locally.
And you can't say that the average American or European had a low standard of living back in the 1980s.
At international conferences, there have indeed been a lot of squabble about how much "climate debt" the developed world has ... as an argument from less developed countries to be be allowed to emit more greenhouse gases.
None of that is productive, of course. We need to realise that it is too late for those kinds of demands. Instead we should focus on the cost: that countries closer to the equator -- which are often the poorer and the least developed, are going to be hit the hardest.
We should be in "damage control" mode already!
Keep in mind that every action we do to affect emissions and the climate has a ~30-year delay before any effect can be measured.
Most current "flagship" phones use multicore CPUs in big.LITTLE configuration.
In most of these the "big" part are cores with speculative execution, which are activated when there is a need for more power. Most exploits in the class that Spectre is in need to first prime the cache and speculator through code in long-running loops (and especially on ARM), which means that they would always be promoted to run on the "big" cores anyway.
I wrote "most phones" above, because some SoC:s, like Snapdragon 835 and 845 have only cores with speculative execution, the "little" cores being also speculative, only clocked lower. These are the cores most used in upcoming Windows 10/ARM laptops.
Indeed. Most current Microsoft tablets are neither functional tablets nor functional PCs but still crippled half-arsed compromises.
The devices need ports, to be able to receive power and forward power to a device that has a single USB lead.
I often use a 8" Lenovo Yoga Tab with Windows 10. The hardware is pretty good except for having only one port. I want a proper OS on it that allows me to do file management.
But Windows' user interface in "tablet mode" is half-assed, and would be completely unusable if the device in question did not support a pen to simulate a mouse. Then there is the issue of screen scaling.
Windows 8 was released to developers in 2011 already. That's SEVEN YEARS in which they could have made it proper.
That's only Microsoft's terminology... Used to make Windows tablets feel special and different from other tablets.
I think he meant homing nubs on the home row's keys. They are used to find the right hand position by touch alone.
Look closely at the F and J keys on a physical keyboard!
I think a bigger issue though is that you can't use muscle memory from physical keyboards on touch screens. Physical keyboards have a very specific layout with each key allocated a 3/4" by 3/4" square and rows being offset 1/2 and 1/4 key. Even Apple's keyboards adhere to that standard (except slightly smaller on the vertical).
Touch screen keyboards very rarely have keys exactly that size, size, shape and staggering. A touch screen would have to be at least 25 cm / 10" wide to fit a regular keyboard layout, which few do.