There should be a standard wireless protocol/device which owners of a building (movie theatre, hospital etc) could use to restrict the capabilities of cell phones within that building: Silent mode, low radiation and/or to disable the camera etc.
Then there wouldn't be a need for additional manpower for enforcement of bans, long lines to cell-phone lockers before and after concerts, or of radio-absorbent paint in movie theatres. etc. Patients would not need to be called back to perform a MRI again because the first one had been disturbed by a cell phone signal. Of course every transmitter would have to be registered and its range enforced by GPS and cryptography: that would be relatively simple to implement actually.
And... emergency calls would still always be possible! Important incoming texts would still be received, just put on hold.
Seriously, Telecom Industry: Get this done already!
1. Microsoft has recently released a "Classic Intellimouse" with the old shape... but don't buy it just yet. The innards are bad. It does not register small moments at low resolution setting and there is angle snapping which can't be turned off. Reviewers have found it unusable for gaming and photo editing.
3. Agree. Touch-screen in cars could be just as dangerous as cell phone use while driving. Stupid Stupid Stupid.
Moore's "Law" has died because manufacturing is approaching hard physical limits: features on the chip are only tens of atoms across, not tends of thousands. CPU manufacturers have to compete on parallelism and better architecture, but unfortunately we are pretty much locked in on the x86 architecture not only on MS Windows but in practice also on Mac and Linux.
For Linux to break out of the Intel hegemony, major distributions would have to start supporting multiple CPU architectures equally. Start requiring that all packages in the main repository get compiled for both x86-64 and say.. 64-bit ARM.
4. Postscript As A GUI Postscript is a Turing-complete language running in a virtual machine. Code injection vulnerabilities in PDF is a real thing that you want to avoid. * Isn't MacOS X's drawing model still based on Display Postscript? * GTK+ uses the Cairo library for its rendering, and it also has PS and PDF backends that might satisfy many needs.
Smart objects on the display server side (which NeWS had) are still missing though. But I think a model with pre-defined well-behaving primitive objects (clickable, popup, draggable, scrollable etc.) sending events would be better.
7. Big, Properly-Sprung Keyboards Have you missed the comeback of mechanical keyboards in recent years? They have got especially popular for PC gaming. If the mainstream widely available gaming mechs are not be to your liking, the mechanical keyboard community is now big and diverse (both users and companies) and there are lots of lesser known options if you look. Check out the Geekhack forum (for "geeks" and "hack writers"). I suspect that you might be especially interested in the TactilePro with new Alps (clone) switches from Matias, or real Model Ms with buckling springs from Unicomp.
Asking users to expose their birth dates is not a good idea. In some countries, birth dates are considered sensitive information. Either way, the data could be harvested by a third party and used for targeted advertising or more nefarious purposes.
What a team, back in the day. Ed Neumeier was also scripitwriter on the Verhoeven-directed RoboCop and a lot of the tone in both movies can be attributed to him. I can definitely feel the same style of humour in both movies.
Neumeier did not work on the RoboCop sequels, and I think a lot of that is why they were so different, without the same edge. And now there are rumours that Neumeier would be working on a stand-alone sequel to the original RoboCop, based off an outline that he wrote decades ago. We'll see... The Starship Troopers sequels weren't very good IMHO so I'm afraid that he could have lost it.
Yes, overflow flags would complicate scheduling and speculation but not necessarily that much. The Mill sets a flag in "meta data" that belongs to the destination "register" and the flag is copied in subsequent instructions using that result. A CPU exception is trapped first when the flag reaches a non-speculated instruction such as a load or store.
Overflow condition checking for a signed addition on RISC-V requires three additional instructions, with two linked dependencies. See here.
I like the way that The Mill architecture (proprietary, not yet in silicon) is going with regards of security features.
It does some things in hardware fast that a microkernel would otherwise do with a penalty compared to current monolithic kernels. For instance, IPC is done through cross-domain calls in one clock cycle. This means that many libraries could be moved into separate protected domains ("services") without loss of performance.
It also has fine-grained memory protection (separate from paging), akin to capabilities in hardware. It also has a separate protected stack for call return-addresses (and spilled register windows) and special encoding for branch-targets, thus being impervious to ROP or Return-to-libc attacks.
While many of the specific mechanisms are patented, the general ideas are not - they are actually very old and have not been in the mainstream. Intel is getting a "shadow stack" for protecting against ROPs in future CPUs.
BTW. Myself I am a little disappointed with RISC-V. It is clearly designed to run C very well but not anything else. There is no direct hardware support for carry/overflow detection, necessary for Swift and Rust as well as bignum libraries, meaning that those would run slower on it than on otherwise comparable architectures.
I love the 680x0. It had the most modern ISA back in its day. But it was a CISC design, not developed past the 68060 at 66MHz, which was comparable to somewhere in-between a Intel '486-DX2 and a Pentium at that clock. Motorola dropped the 68K in favour of the 88000 and then that for the PowerPC supposedly after it had been revealed that the 88K architecture had serious design flaws. You can today run a 68040 on a FPGA at 100 MHz though. (Vampire card for the Amiga).
There is an open-hardware 32-bit RISC architecture that is somewhat similar to program assembly for: J-Core, based on the Super-H. The JC2 is based on SH2 ISA and has a BSD-style license. Nowadays, the patents for the SH4 ISA should also have expired, meaning that developed could continue. It might not be the fastest CPU architecture (only 16 regs and two-address code like M68K), but it is denser than ARM Thumb and could be useful for at least embedded systems. (In fact ARM once licensed patents from Hitachi for making ARM Thumb.)
I wish they would discontinue all their cell phones. "Smart" phones have turned people into antisocial idiots, antisocial in that they have forgot how to properly interact with people in their immediate physical surroundings as the people on the other side or the app they are in have taken their attention.
Sorry for the rant, but I just had an encounter with an idiot in the grocery store and I am still pissed. Not that it does not happen every day though.
Saying "Thank you" is part of the protocol that us humans use in social interaction. It is no different from how a serial or network protocol would send an "ACK" code. Without those codes, digital communication protocols wouldn't work properly either.
In fact the term "protocol" in computing is a metaphor for human interaction - specifically interaction between diplomats.
You are generalising. Introduction of DAB radio is not the same thing as choosing to abandon FM radio. Most of Eastern and Central Europe don't have any DAB broadcasts at all and most of the others are only doing trials. Sweden has decided not to discontinue FM radio broadcasts for the time being after strong objections from the Ministry of Defence (emergency broadcasts) and because of lack of customer demand for DAB radio.
People tend to instead replace their FM radios with personalised streaming services on their cell phones, for which there is also more commercial interest.
DAB does not offer any tangible benefits over mobile streaming and FM. In good conditions, DAB could provide either better audio quality or more channels than FM, but not both. In bad conditions, weak reception of emergency broadcasts over FM can still be intelligible where as the same over DAB would just cut off.
The researchers have not proven that AMD processors could not be affected by a future tweaked version of Meltdown. They have just not been able to perform Meltdown on AMD themselves yet. I suppose that Microsoft is therefore choosing to err on the side of caution.
I was one of those who called "no way" at first, but just yesterday I found this quote from an Intel engineer. It was originally posted in a reddit thread but has since been deleted - but not before being confirmed by other former engineers at Intel.
As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
Why?
Let me set the scene: It's late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times... we can't live forever in the shadow of the early 90's FDIV bug, we need to move on. Our competition is moving much faster than we are" - I'm paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn't explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signalled a sea change at Intel to many of us who were there. And it didn't seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
Cheap small laptops don't really exist on the market any more, and most that do are 2:1 devices: tablet first and laptop second. The next step up is a full-spec'd "ultraportable" laptop, and those cost a lot more. Overall, either type don't have many ports either and with no upgrade options to be as thin as possible.
I have replaced my old netbook with a Lenovo Yoga Tab 8" Windows 8 tablet from 2015. 1920*1200 8" screen (16:10, 283 PPI), Micro SD-card reader (more storage), WiFi, BT, GPS, front and back cameras. It has a thick bulge on one side - but that only makes it easier to grip and it has got a built-in stand. Unlike other tablets, you can use a regular pencil (or any conductive tip) as a stylus -- which is pretty darn essential in Windows if you don't have a BT mouse or trackpad. And I got it for just over $200. The downsides are the Atom CPU, 2G RAM and 32G storage but it got a SD-card reader. There is only one micro-USB port for charging and peripherals, so a BT keyboard is necessary. There was also a 10" version and successors Yoga Tab 2, where the 10" came with a keyboard "accessory" and I think they were available first with Windows 8.1 and then Windows 10. Unfortunately, Lenovo has discontinued the Windows versions and the contemporary Yoga Tab 3 runs Android on ARM.
SPARC, MIPS and PowerPC may be fringe but they are still out there in the fringe for servers and/or supercomputers. Several CPUs of each architecture were released in 2017.
IBM's POWER chips have supported the full PowerPC ISA for a decade and its performance is very competitive to Intel XEON, if not surpassing.
Oracle (which had bought Sun) closed their SPARC processor group last year though. Fujitsu may still be active.
Chinese Loongson makes MIPS processors at 1.5GHz, but they would need to step it up to compete.
I have not checked PowerPC or SPARC but MIPS is not vulnerable to Meltdown. Linux on MIPS can not leak any kernel pages -- simply because MIPS does not do paging in kernel mode.
No, they did test their Meltdown code on AMD and ARM but were not able to reproduce it on the chips they tested on. That does not prove that a Meltdown-like attack on AMD or ARM is impossible, either on a different chip they did not test on or with a tweaked version of Meltdown.
From the actual article ("meltdown.pdf"):
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
There are technical reasons also. Android under the Linux kernel does sandboxing by giving each app its own user, which I find to be a bit of a kludge.
Fuchsia's microkernel Zircon (nee Magenta) instead uses capability-based security, in a model where Processes live in Jobs and Jobs can be nested, allowing the ones that are deeper nested having lesser privileges. However, Zircon has a major flaw: capabilities can not be revoked, other than by killing the whole process, or jobs. If I had been in charge, I would have instead chosen seL4, which has revocation, is stable on ARM and which has a formal proof of correctness (was it ten or twenty man-years of work just for the proof? I forget). But, yeah... seL4 is licensed under GPL.;-P
Slashdot Mirror
A repost from the poll thread:
There should be a standard wireless protocol/device which owners of a building (movie theatre, hospital etc) could use to restrict the capabilities of cell phones within that building: Silent mode, low radiation and/or to disable the camera etc.
Then there wouldn't be a need for additional manpower for enforcement of bans, long lines to cell-phone lockers before and after concerts, or of radio-absorbent paint in movie theatres. etc. Patients would not need to be called back to perform a MRI again because the first one had been disturbed by a cell phone signal.
Of course every transmitter would have to be registered and its range enforced by GPS and cryptography: that would be relatively simple to implement actually.
And... emergency calls would still always be possible! Important incoming texts would still be received, just put on hold.
Seriously, Telecom Industry: Get this done already!
1. Have you tried X11 over ssh? ;-P
2. Then a small spelling error in your code could create a real mess instead of a fault.
1. Microsoft has recently released a "Classic Intellimouse" with the old shape ... but don't buy it just yet.
The innards are bad. It does not register small moments at low resolution setting and there is angle snapping which can't be turned off.
Reviewers have found it unusable for gaming and photo editing.
3. Agree. Touch-screen in cars could be just as dangerous as cell phone use while driving. Stupid Stupid Stupid.
Moore's "Law" has died because manufacturing is approaching hard physical limits: features on the chip are only tens of atoms across, not tends of thousands.
CPU manufacturers have to compete on parallelism and better architecture, but unfortunately we are pretty much locked in on the x86 architecture not only on MS Windows but in practice also on Mac and Linux.
For Linux to break out of the Intel hegemony, major distributions would have to start supporting multiple CPU architectures equally. Start requiring that all packages in the main repository get compiled for both x86-64 and say.. 64-bit ARM.
1. Transputer
Check out:
* The REX Neo architecture
* Coherent Logix' HyperX (not to be confused with the PC component brand)
4. Postscript As A GUI
Postscript is a Turing-complete language running in a virtual machine. Code injection vulnerabilities in PDF is a real thing that you want to avoid.
* Isn't MacOS X's drawing model still based on Display Postscript?
* GTK+ uses the Cairo library for its rendering, and it also has PS and PDF backends that might satisfy many needs.
Smart objects on the display server side (which NeWS had) are still missing though. But I think a model with pre-defined well-behaving primitive objects (clickable, popup, draggable, scrollable etc.) sending events would be better.
7. Big, Properly-Sprung Keyboards
Have you missed the comeback of mechanical keyboards in recent years? They have got especially popular for PC gaming. If the mainstream widely available gaming mechs are not be to your liking, the mechanical keyboard community is now big and diverse (both users and companies) and there are lots of lesser known options if you look. Check out the Geekhack forum (for "geeks" and "hack writers").
I suspect that you might be especially interested in the TactilePro with new Alps (clone) switches from Matias, or real Model Ms with buckling springs from Unicomp.
Asking users to expose their birth dates is not a good idea.
In some countries, birth dates are considered sensitive information.
Either way, the data could be harvested by a third party and used for targeted advertising or more nefarious purposes.
I'll choose another airline then.
There is a distinction between controls for an app and controls for a window manager.
These are two different concepts and should not be muddled up.
Similarly, should an app be able to bind Alt+Tab for its own use? No, of course not.
What a team, back in the day. Ed Neumeier was also scripitwriter on the Verhoeven-directed RoboCop and a lot of the tone in both movies can be attributed to him. I can definitely feel the same style of humour in both movies.
Neumeier did not work on the RoboCop sequels, and I think a lot of that is why they were so different, without the same edge.
And now there are rumours that Neumeier would be working on a stand-alone sequel to the original RoboCop, based off an outline that he wrote decades ago. We'll see...
The Starship Troopers sequels weren't very good IMHO so I'm afraid that he could have lost it.
1. It is computationally expensive.
2. While parts of it are royalty-free, algorithms for faster compression and decompression is patented.
Yes, it is used for Digital Cinema, but systems in movie theatres always use special hardware for decompression.
Yes, overflow flags would complicate scheduling and speculation but not necessarily that much. The Mill sets a flag in "meta data" that belongs to the destination "register" and the flag is copied in subsequent instructions using that result. A CPU exception is trapped first when the flag reaches a non-speculated instruction such as a load or store.
Overflow condition checking for a signed addition on RISC-V requires three additional instructions, with two linked dependencies. See here.
I like the way that The Mill architecture (proprietary, not yet in silicon) is going with regards of security features.
It does some things in hardware fast that a microkernel would otherwise do with a penalty compared to current monolithic kernels. For instance, IPC is done through cross-domain calls in one clock cycle.
This means that many libraries could be moved into separate protected domains ("services") without loss of performance.
It also has fine-grained memory protection (separate from paging), akin to capabilities in hardware. It also has a separate protected stack for call return-addresses (and spilled register windows) and special encoding for branch-targets, thus being impervious to ROP or Return-to-libc attacks.
While many of the specific mechanisms are patented, the general ideas are not - they are actually very old and have not been in the mainstream. Intel is getting a "shadow stack" for protecting against ROPs in future CPUs.
BTW. Myself I am a little disappointed with RISC-V. It is clearly designed to run C very well but not anything else. There is no direct hardware support for carry/overflow detection, necessary for Swift and Rust as well as bignum libraries, meaning that those would run slower on it than on otherwise comparable architectures.
I love the 680x0. It had the most modern ISA back in its day. But it was a CISC design, not developed past the 68060 at 66MHz, which was comparable to somewhere in-between a Intel '486-DX2 and a Pentium at that clock.
Motorola dropped the 68K in favour of the 88000 and then that for the PowerPC supposedly after it had been revealed that the 88K architecture had serious design flaws.
You can today run a 68040 on a FPGA at 100 MHz though. (Vampire card for the Amiga).
There is an open-hardware 32-bit RISC architecture that is somewhat similar to program assembly for: J-Core, based on the Super-H. The JC2 is based on SH2 ISA and has a BSD-style license.
Nowadays, the patents for the SH4 ISA should also have expired, meaning that developed could continue.
It might not be the fastest CPU architecture (only 16 regs and two-address code like M68K), but it is denser than ARM Thumb and could be useful for at least embedded systems. (In fact ARM once licensed patents from Hitachi for making ARM Thumb.)
I wish they would discontinue all their cell phones.
"Smart" phones have turned people into antisocial idiots, antisocial in that they have forgot how to properly interact with people in their immediate physical surroundings as the people on the other side or the app they are in have taken their attention.
Sorry for the rant, but I just had an encounter with an idiot in the grocery store and I am still pissed. Not that it does not happen every day though.
There are also economists who are complaining that we are not recycling old clothes as much as we should.
Who is right?
Saying "Thank you" is part of the protocol that us humans use in social interaction.
It is no different from how a serial or network protocol would send an "ACK" code. Without those codes, digital communication protocols wouldn't work properly either.
In fact the term "protocol" in computing is a metaphor for human interaction - specifically interaction between diplomats.
But! ... 1h 21m is two hours in consumer electronics mathematics!
Just as 7680 is eight thousand.
You are generalising. Introduction of DAB radio is not the same thing as choosing to abandon FM radio. Most of Eastern and Central Europe don't have any DAB broadcasts at all and most of the others are only doing trials.
Sweden has decided not to discontinue FM radio broadcasts for the time being after strong objections from the Ministry of Defence (emergency broadcasts) and because of lack of customer demand for DAB radio.
People tend to instead replace their FM radios with personalised streaming services on their cell phones, for which there is also more commercial interest.
DAB does not offer any tangible benefits over mobile streaming and FM. In good conditions, DAB could provide either better audio quality or more channels than FM, but not both.
In bad conditions, weak reception of emergency broadcasts over FM can still be intelligible where as the same over DAB would just cut off.
... you are attending a Weird Al concert?
... as far as we know.
The researchers have not proven that AMD processors could not be affected by a future tweaked version of Meltdown. They have just not been able to perform Meltdown on AMD themselves yet.
I suppose that Microsoft is therefore choosing to err on the side of caution.
I was one of those who called "no way" at first, but just yesterday I found this quote from an Intel engineer. It was originally posted in a reddit thread but has since been deleted - but not before being confirmed by other former engineers at Intel.
Cheap small laptops don't really exist on the market any more, and most that do are 2:1 devices: tablet first and laptop second. The next step up is a full-spec'd "ultraportable" laptop, and those cost a lot more.
Overall, either type don't have many ports either and with no upgrade options to be as thin as possible.
I have replaced my old netbook with a Lenovo Yoga Tab 8" Windows 8 tablet from 2015. 1920*1200 8" screen (16:10, 283 PPI), Micro SD-card reader (more storage), WiFi, BT, GPS, front and back cameras. It has a thick bulge on one side - but that only makes it easier to grip and it has got a built-in stand.
Unlike other tablets, you can use a regular pencil (or any conductive tip) as a stylus -- which is pretty darn essential in Windows if you don't have a BT mouse or trackpad.
And I got it for just over $200. The downsides are the Atom CPU, 2G RAM and 32G storage but it got a SD-card reader. There is only one micro-USB port for charging and peripherals, so a BT keyboard is necessary. There was also a 10" version and successors Yoga Tab 2, where the 10" came with a keyboard "accessory" and I think they were available first with Windows 8.1 and then Windows 10.
Unfortunately, Lenovo has discontinued the Windows versions and the contemporary Yoga Tab 3 runs Android on ARM.
SPARC, MIPS and PowerPC may be fringe but they are still out there in the fringe for servers and/or supercomputers.
Several CPUs of each architecture were released in 2017.
IBM's POWER chips have supported the full PowerPC ISA for a decade and its performance is very competitive to Intel XEON, if not surpassing.
Oracle (which had bought Sun) closed their SPARC processor group last year though. Fujitsu may still be active.
Chinese Loongson makes MIPS processors at 1.5GHz, but they would need to step it up to compete.
I have not checked PowerPC or SPARC but MIPS is not vulnerable to Meltdown. Linux on MIPS can not leak any kernel pages -- simply because MIPS does not do paging in kernel mode.
No, they did test their Meltdown code on AMD and ARM but were not able to reproduce it on the chips they tested on.
That does not prove that a Meltdown-like attack on AMD or ARM is impossible, either on a different chip they did not test on or with a tweaked version of Meltdown.
From the actual article ("meltdown.pdf"):
There are technical reasons also. Android under the Linux kernel does sandboxing by giving each app its own user, which I find to be a bit of a kludge.
Fuchsia's microkernel Zircon (nee Magenta) instead uses capability-based security, in a model where Processes live in Jobs and Jobs can be nested, allowing the ones that are deeper nested having lesser privileges. ;-P
However, Zircon has a major flaw: capabilities can not be revoked, other than by killing the whole process, or jobs.
If I had been in charge, I would have instead chosen seL4, which has revocation, is stable on ARM and which has a formal proof of correctness (was it ten or twenty man-years of work just for the proof? I forget).
But, yeah... seL4 is licensed under GPL.