> I use very high end software that runs on Windows and currently nothing else. All the idiots that keep telling me to use Linux (I already do when I can) do not understand the reality of most people's situations.
That's not MOST people's situations, that's YOUR situation. MOST people could switch totally to Linux. There are some people who could not, but whatever your "very high end software that runs on Windows and currently nothing else", it doesn't sound like MOST people using that. The most common thing with Windows is "WINE doesn't support $RECENT_GAME, screw Linux imma stay on Windows and put up with anything". That's not the same as "I need Windows for compatibility with this professional program". Plenty of people with that use case, but definitely not "most".
Your bitching would have more merit if Windows 7, 8, 8.1, and 10 didn't have radically different UIs.
MATE, is an alternative to GNOME. The Windows equivalent roughly would be whether you have a version of windows explorer with a start menu and bar at the bottom (ex: MATE), or some tiled bullshit with oddities. MATE is closer to the classic Windows interface than modern Windows interfaces are.
While everyone will bitch about (with merit) or rave about (maybe with merit) the actual details of the budget, the big requirement this time, MIGHT be, it actually be a budget.
I'm not sure if the current proposed budget seriously expects the debt ceiling to remain in effect. What is sure is that the debt ceiling has been punted in the past: hence it being suspended until yesterday. Talking about the budget without any decision on the debt ceiling is pretty stupid, but we will do it anyway. If the debt ceiling is real, we probably need to cut more than 18% off of a few things, and eliminate more than just a few programs- we probably need to axe at least one department over the next few years. If instead it is just another punt to younger people to pay off our national credit card, then you can go ahead and parse the proposed budget through a petty and partisan lens.
You're missing the point. Sure, the group that would actually run an open version is small. But this would grant assurance that there isn't a back door. There's never a guarantee about a bug that grants access in some manner, but if the PSP was open source, or even if there was just an open source version you COULD install (with or without remote management, leaving the closed source one as the default), everyone would have assurance that the AMD chips are not backdoored at factory, on purpose. The odds of that are low today, but why not take them to zero?
Here's the thing: not only might that be detectable (low odds, but the company is DONE, full stop), but if you're MOVing shit to my AX register, you already own me. Or ANY opcode at all. If I'm running your code straight, you obviously have everything or almost everything. If you're getting me through some javascript bullshit where it hopefully runs the opcode, your fishing, and I have mitigations.
The problem with an entire suite of encrypted and signed software running at ring minus 3 is that there's no limit to the functionality you could embed, and since that software has raw access to at least some of the networking, you may have any number of ways to get in.
So this isn't some academic thing: the existence of Intel's ME and AMD's PSP is a real risk. The idea that the chip may have magic numbers of some secret tap pattern is way less concerning, given that you can connect to a network without just running some guy's opcodes.
The current "identify some bullshit" captchas can be done without javascript. This seems unlikely to have that failsafe. It will be a wad of purposefully hard to reverse engineer javascript, probably with some timing crap to make it hard to do anything with, and that will be that. It will of course ultimately end up generating telemetry.
I sound pessimistic, but this has been the direction we've been heading for some time.
> In other words, you could push the most intrusive, malevolent, destructive code to a user's device at will with no oversight.
That's absolutely the risk.
> Who thought having this capability was a good idea?
I think it is for online games and other situations where a bug might otherwise mean a server outage until it could go through a code review. It's still a terrible idea.
Anyway, I would suspect that the timing of this is not a coincidence, given the vulnerabilities alluded to in the news recently.
If all software ran on all platforms, all software would suck, and as a result, all platforms would suck too.
All software includes real time software, right? So every platform has to be an RTOS. It also needs to NOT be an RTOS, at the same time. So right away, that's impossible, and the "UCSA" in question is faced with a FUNDAMENTAL issue.
Wii Bowling requires a Wii-mote, and is tested as such. Would it work as well with a touch screen? What about with a keyboard and mouse? What about with a keyboard? What about just with a PS2 controller? What about with a flightstick?
Replace "Wii Bowling" with any production application, with a SQL database, with gvim, with World of Warcraft, with a home coded neural net, with an arcade game, with whatever. Which of those have inputs that would be useful?
A program optimized for a 4k Display, running on a 1080p television would be lame, right? What about a tiny app that makes assumptions about resolution running on something much bigger?
So, already the idea sucks because the INPUTS and the OUTPUTS are vastly different across devices.
Lets take to internals. If you don't have enough RAM, do you swap to hard disk? Do you swap to SSD? Wait, swapping to SSD totally hammers its reliability. Do you build future programs for a small amount of RAM? Not everything scales with the user's demands. Some machines are very good at some kinds of memory operations, and others better at others. This guides how programs are built and tested on those architectures. The "UCSA" programs would have to establish limits on RAM, just as you say, but there's a bunch of factors about RAM besides quantity. By the time you are done enumerating, you don't have something very universal.
Finally, the one part that has gotten real and persistent attention- what about the CPU? Every CPU is good at different shit. Hardware optimizations can make a big difference. Intel's transactional opcodes can vastly increase performance on some chips, cause hard lockups on other (bugged) chips, and are not present at all in any of Intel's competition. Languages that compile to bytecode instead of opcode skip this, and Java and other cross platform approaches give a good chance of code that is hardware independent. But Java has to virtualize a lot of the assumptions made as well. The "UCSA" will have at least as many assumptions as Java. It will require an additional layer of API to talk to the drivers, which will not be trivial with stuff that needs to talk to graphics cards. This additional layer will need to support all the varieties, meaning that an update to Vulcan will require a new version, as will an update to Direct-X, etc.
Also, this approach is entirely future-blind. What does a chip with a built in FPGA look like to your universal software thing? Does it have to universalize FPGA programming and utilization as well? An algorithm meant for FPGA usage may be shockingly slow if dragged into the CPU and executed. What if the universal software needs random numbers? There's a huge difference in how random numbers can be, and this cannot be virtualized away. If you expose that your numbers are generated by the CPU instead of an exeternal RNG, then the application can refuse to run without secure random numbers, making it not universal. If you abstract that away, then your crypto program may never run the way it needs to- it may be totally useless. What about something further away, like a quantum compute card, or whatever?
> I'm going to risk the inevitable downmod from the rabid hard right and alt-right types by finally thinking that we have maybe another six to nine months before even a majority of Republicans in Congress begin planning to remove this imbecile from office.
Ah, pause your actions, all! Heed and record the March prediction from MightyMartian!
We'll add this to the February prediction of "I honestly think Bannon's days are numbered", the January prediction of "Congress is going to start moving to claw back the Presidency's legislatively enabled executive powers", the December prediction of " a man of Trump's age is unlikely to be seeking a second term" (he registered for 2020 on the evening of inauguration day, so he is, unprecedentedly, the only declared 2020 candidate), and of course the November prediction that "I am so going to enjoy rubbing it into Trump supporter's faces on Wednesday.".
> Everytown for Gun Safety has no interest whatsoever in "gun safety".
No, they're just another bunch of gun grabbing tyrants.
But, the topic isn't about them, and how much they suck. It's about whether it is at all ok for Snapchat to basically try to extort them by asking for cash or threatening to play a countermessage.
It's phrased cleverly enough to avoid any legal issues, probably- they simply mention that the NRA is talking about buying advertisement time- but that is clearly meant as a threat.
Anyway, it seems fucking dirty, right? If they are doing this to one organization, they'll probably do it to more. It's probably a pretty effective technique.
Like OpenRex? I don't know exactly how you can find good solid open hardware, but I know you pretty much have to turn to ARM for that.
My point is, that activism crap is totally offtopic when a system integrator company comes out and asks what Linux based developers need in a laptop.
"What do you need in an x86 Linux laptop?" "Obviously, it needs to not be x86, and to use an ARM chip that doesn't exist yet, using software that only partly exists"
SUPER HELPY
This is not a fight to take to Razer. OP should take this crap to AMD or Intel, who are responsible for the current state of ring -3 type affairs.
Under Windows, the keys have an idiotic default function- call up a menu. Which in a full screen app, makes it flip graphic modes, etc. And in a windowed app, defocuses it. For an OS that brags about games though, it sure is nuts that they put "lose the game" right between "fire" and "jump". But under Linux, you've never been as trapped by this crap as you were under Windows, and you can make the meta keys do whatever you want, or nothing at all.
But you still have it under there, doing something- this just seems to make it network blind. That's a pretty good start.
What if you don't have like, whatever chip programmer this approach needs, and/or other incompatible hardware?
Is it beneficial to cut off a potential ME backdoor via blocking ports at your (non-x86) router? Which ports would give you the best defense? Is it beneficial to use a non-mobo based network card (wifi or ethernet), in the hopes that the ME won't be smart enough to monitor that? Aka, are most firmware network stacks all about the network functionality built into the mobo? Are there any other general mitigations that should be followed?
Basically, what is best practice to mitigate this on modern hardware, given that you are on a piece of hardware that you cannot or will not perform the hardware hackery required to blank some of its pages?
Most of this post also works for AMD if you swap Intel->AMD and ME->PSP.
> A truly free and open-source software laptop... which allows a FOSS BIOS or UEFI replacement, FOSS drivers. No Blobs, or Intel ME.
Fuck off.
Yes, what you say would be perfect. But that is not something that Razer, as a system integrator and builder, gets to pick. There's NO Intel chips without the ME. There's ZERO AMD chips without the PSP, which is the rough equivalent of the ME (and has all the same issues YOU care about that ME does). Razer is trying to build a machine for developers, as they say here, and you are saying "Well, first of all, lets totally avoid x86". Does that sound like something that will sell to x86 developers?
> Journalists, activists, and anyone who must have a secure, trusted computing device
Which will never be built by fucking Razer, and you know it. This is Razor trying to expand from just slapping LEDs on everything. A Razer Linux laptop should have features like "the Meta key should not have a stupid Windows logo on it for some reason" and "the rainbow LEDs should be configurable in the BIOS, and not just via a proprietary configurator written in Java that still manages to only support Windows".
At best, you can argue for open specifications where they could be put, given that it is meant to be able to be used for open source software.
But to solve the issues you are talking about is not the problem of a laptop manufacturer. It represents a deep set of issues embedded up and down the supply chain. Bitch about that. Go grief AMD and ask them to make a chip compatible with libreboot- don't act like Razer is gonna solve this issue, or that they even should try.
> The underlying OS doesn't really matter too much.
Sure it does. With Windows, your keyboard input is sent to Microsoft, to help them, uh, personalize your input experience. Or whatever their reasoning is. Every time you open notepad, gotta send packets to Microsoft. Gvim on Linux doesn't have this, err, feature. This is a "feature" that not even emacs has!
> It'll be interesting to see if the release of the Nintendo Switch recovers some of this loss.
It won't. More importantly, it can't.
This loss is based on speculation- this is about Gamestop's stock market price. It is going down because people are assuming that the company is more likely to experience hardship as a result of Microsoft's latest whatevermajig.
The Switch, on the other hand, is a known quantity, and everyone is assuming it will sell out immediately, because Nintendo never makes enough for their demand. So if Gamestop sells every Switch that they see, that's what everyone is assuming. And it isn't like Gamestop has some great claim on the Switch as opposed to say, Best Buy, Wal*mart, Amazon, Toys Backwards "R" Us, etc. The Switch games could outsell predictions, and that would help the whole retail video game sector, but it is unlikely to be a huge driver, given that it is just one of many categories of products sold.
The Switch could be a success, or a moderate failure, and not impact Gamestop's stock price much- or their bottom line, really.
Keep in mind that stock prices at best only represent a best guess situation anyway.
> Games have notoriously been single threaded for ever, because it's a lot easier to program a linear algorithm and keep memory use clean.
Some things games have to do are fundamentally single threaded, but you are correct: it's easier to program a single thread, and often the gain from another thread doesn't help much. 3D games are a little different, because much of the CPU tasking involves doing stuff so that data can be pushed to the graphics card. Those scale VERY well with extra cores, but only if coded that way.
An example is the MMO Star Wars: The Old Republic. In any area where there is not many players, the CPU has almost nothing to do. It continuously funnels requests for frames to the graphics card, which goes totally bonkers rendering hundreds of frames per second, and spinning its fan like crazy (there's a vsync option, should you be looking for a solution to this issue, and also be running fullscreen). In an area where there's a ton of players, your frame rate drops below 60 fps, and sometimes even below 30 fps, and the graphics card fan is silent. Check out the processor status, and you see the CPU dance:
And a bit of investigation reveals that the process is barely multithreaded at all.
Meanwhile, other games don't have this issue: they divest that logic across the cores, and the graphics card can be fully tasked (ideally intelligently so), giving you a good framerate consistently, with your GPU fan starting up if the game is actually rendering something hard.
But again, that requires those games be programmed that way. And more are being programmed that way today. Mostly, game developers have been happy to take the much simpler single threaded approach, which reduces development costs, and if you have to support a bunch of dual core chips because a decent chunk of your customers have those, why spend your time worrying about the extra cores most chips have? That's not necessarily how all future development will go, however, especially if, as is being made obvious, that adding more cores is a lot more reasonable than adding a little bit of IPC and clock.
> No, the answer is that single threaded is nearly always more important than multi-threaded, because you are doing single threaded tasks about 99% of the time.
The answer is nowhere near that simple. If your single threaded task is any manner of I/O bound- disk, network, or memory, then you can't speed it up any further with a faster CPU, on clock or IPC. If PARTS of it are bound in those ways, then a faster processor will help, but not linearly.
But in general, if you had a choice between a 4 GHz 8 core processor and an 8 GHz 4 core processor, you'd take the faster chip. But that has NEVER been the comparison, and that's why YOUR USE CASE matters, and why single threaded performance is not always the answer. In the top end desktop useage, you'll usually pick between something like the i7-6900K (Intel's 8 core desktop offering, stable up to 4.3 GHz, a Broadwell piece released middle of last year) and the i7-7700K (Intel's very latest 4 core desktop offering, some of which are stable up to 5 GHz, a Kabylake piece two generations advanced from Broadwell). And when these are benchmarked, you see that CPU bound tasks that are single threaded are in fact a bit faster on the Kabylake, which has both slightly improved instructions per clock over the broadwell piece, and a faster clock speed, but that anything that can make use of the cores is a LOT faster on the Broadwell chip.
More relevantly, you get to make this tradeoff at many prices, and the reason you are normally going to recommend the higher singlethreaded performance is because the piece with the more core, while way hella better in multithreaded parts, usually costs more. Doubling cores doesn't double performance in multithreaded, but it isn't too far off in some cases. Meanwhile, a 20% increase in clock speed normally gets you almost 20% more performance on single threaded.
AMD's chips are coming in at prices that are competitive with the 4 core desktop chip, while offering performance that competes with the 8 core desktop/enthusiast pieces. That's why this is important.
And why your use case matters.
And your use case is probably going to favor more cores, going forward. Only you know better for you, of course, but as a general recommendation it is worth pointing out.
The 1800X is like 8 cores to the 7700K's 4 cores. The 7700K, having half the cores, will presumably do better on single threaded tasks, such as the benchmarks in question. Future code, especially that which makes requests to the GPU in a multithreaded fashion, will perform better with more damned cores. For single threaded (or basically that), the 7700K also blows away Intel's 6950X, their top desktop CPU offering with 10 cores.
A better comparison per price point would be the 1700X or 1700 to the 7700K. Again, you find that the 8 core chip blows away the 4 core chip on multiprocessing, with less amazing results from a single thread.
There's a ton of applications that scale well with cores, and games will begin to do so more in the future. There will always be tasks that can't be parallelized, but the question is, when do they matter versus the ones that can? The question of cores versus speed per dollar is about as old as CPUs, and the answer is always "what is your use case".
Replication doesn't happen on its own. If it did, we wouldn't have cells, and hell, viruses wouldn't need them to replicate either.
The question you are probably asking, that I don't know the answer to, is "what are the odds that a given one of these strands contains instructions that, when put in some kind of cell, would end up creating a virus". I'd imagine the odds would be really steep... but hey, you'd only need one part to behave like that, right?
> Still, it's notable that bitcoin has (at least temporally) surpassed the price of gold.
Bullshit, it has not.
There's a cap of 21 million bitcoins. Of this, over three quarters have already been mined. It is supposed to get progressively harder to mine bitcoins, with the intention that the huge numbers of bitcoins that are sitting fallow will eventually appreciate in value, that it will still be worth mining them even as they get harder, etc. Regardless of your views on this, or cryptocurrencies: there's only 21 million bitcoins total.
1 bitcoin is one twenty-millionth of all bitcoins. It is about.000005% of the total blob of bitcoins that will ever be..000005% of all the gold mined to date- which is definitely not all the gold ever- is around 300 ounces of gold. And that's a very low estimate for the total gold available- some sources have it at over ten times that in available gold. The fact that no one has it pinned down to at least a solid order of magnitude is depressing, but the point is that even the low estimates, the percentage of one bitcoin compared to all the bitcoin, versus that same percentage of gold compared to all the gold, is nowhere close in bitcoins favor.
Slashdot Mirror
It's not "The PC industry" doing this. It is literally JUST Microsoft.
> I use very high end software that runs on Windows and currently nothing else. All the idiots that keep telling me to use Linux (I already do when I can) do not understand the reality of most people's situations.
That's not MOST people's situations, that's YOUR situation. MOST people could switch totally to Linux. There are some people who could not, but whatever your "very high end software that runs on Windows and currently nothing else", it doesn't sound like MOST people using that. The most common thing with Windows is "WINE doesn't support $RECENT_GAME, screw Linux imma stay on Windows and put up with anything". That's not the same as "I need Windows for compatibility with this professional program". Plenty of people with that use case, but definitely not "most".
Your bitching would have more merit if Windows 7, 8, 8.1, and 10 didn't have radically different UIs.
MATE, is an alternative to GNOME. The Windows equivalent roughly would be whether you have a version of windows explorer with a start menu and bar at the bottom (ex: MATE), or some tiled bullshit with oddities. MATE is closer to the classic Windows interface than modern Windows interfaces are.
> At what point do people get fed up and switch to something else?
I'm pretty sure Windows users will put up with anything.
While everyone will bitch about (with merit) or rave about (maybe with merit) the actual details of the budget, the big requirement this time, MIGHT be, it actually be a budget.
Or at least, soon.
https://www.bloomberg.com/view...
I'm not sure if the current proposed budget seriously expects the debt ceiling to remain in effect. What is sure is that the debt ceiling has been punted in the past: hence it being suspended until yesterday. Talking about the budget without any decision on the debt ceiling is pretty stupid, but we will do it anyway. If the debt ceiling is real, we probably need to cut more than 18% off of a few things, and eliminate more than just a few programs- we probably need to axe at least one department over the next few years. If instead it is just another punt to younger people to pay off our national credit card, then you can go ahead and parse the proposed budget through a petty and partisan lens.
You're missing the point. Sure, the group that would actually run an open version is small. But this would grant assurance that there isn't a back door. There's never a guarantee about a bug that grants access in some manner, but if the PSP was open source, or even if there was just an open source version you COULD install (with or without remote management, leaving the closed source one as the default), everyone would have assurance that the AMD chips are not backdoored at factory, on purpose. The odds of that are low today, but why not take them to zero?
Oh ya, also that would need to be at least eax, ebx, ecx, edx :P
> mov ax, 0xDEADBEEF
Here's the thing: not only might that be detectable (low odds, but the company is DONE, full stop), but if you're MOVing shit to my AX register, you already own me. Or ANY opcode at all. If I'm running your code straight, you obviously have everything or almost everything. If you're getting me through some javascript bullshit where it hopefully runs the opcode, your fishing, and I have mitigations.
The problem with an entire suite of encrypted and signed software running at ring minus 3 is that there's no limit to the functionality you could embed, and since that software has raw access to at least some of the networking, you may have any number of ways to get in.
So this isn't some academic thing: the existence of Intel's ME and AMD's PSP is a real risk. The idea that the chip may have magic numbers of some secret tap pattern is way less concerning, given that you can connect to a network without just running some guy's opcodes.
The current "identify some bullshit" captchas can be done without javascript. This seems unlikely to have that failsafe. It will be a wad of purposefully hard to reverse engineer javascript, probably with some timing crap to make it hard to do anything with, and that will be that. It will of course ultimately end up generating telemetry.
I sound pessimistic, but this has been the direction we've been heading for some time.
> In other words, you could push the most intrusive, malevolent, destructive code to a user's device at will with no oversight.
That's absolutely the risk.
> Who thought having this capability was a good idea?
I think it is for online games and other situations where a bug might otherwise mean a server outage until it could go through a code review. It's still a terrible idea.
Anyway, I would suspect that the timing of this is not a coincidence, given the vulnerabilities alluded to in the news recently.
If all software ran on all platforms, all software would suck, and as a result, all platforms would suck too.
All software includes real time software, right? So every platform has to be an RTOS. It also needs to NOT be an RTOS, at the same time. So right away, that's impossible, and the "UCSA" in question is faced with a FUNDAMENTAL issue.
Wii Bowling requires a Wii-mote, and is tested as such. Would it work as well with a touch screen? What about with a keyboard and mouse? What about with a keyboard? What about just with a PS2 controller? What about with a flightstick?
Replace "Wii Bowling" with any production application, with a SQL database, with gvim, with World of Warcraft, with a home coded neural net, with an arcade game, with whatever. Which of those have inputs that would be useful?
A program optimized for a 4k Display, running on a 1080p television would be lame, right? What about a tiny app that makes assumptions about resolution running on something much bigger?
So, already the idea sucks because the INPUTS and the OUTPUTS are vastly different across devices.
Lets take to internals. If you don't have enough RAM, do you swap to hard disk? Do you swap to SSD? Wait, swapping to SSD totally hammers its reliability. Do you build future programs for a small amount of RAM? Not everything scales with the user's demands. Some machines are very good at some kinds of memory operations, and others better at others. This guides how programs are built and tested on those architectures. The "UCSA" programs would have to establish limits on RAM, just as you say, but there's a bunch of factors about RAM besides quantity. By the time you are done enumerating, you don't have something very universal.
Finally, the one part that has gotten real and persistent attention- what about the CPU? Every CPU is good at different shit. Hardware optimizations can make a big difference. Intel's transactional opcodes can vastly increase performance on some chips, cause hard lockups on other (bugged) chips, and are not present at all in any of Intel's competition. Languages that compile to bytecode instead of opcode skip this, and Java and other cross platform approaches give a good chance of code that is hardware independent. But Java has to virtualize a lot of the assumptions made as well. The "UCSA" will have at least as many assumptions as Java. It will require an additional layer of API to talk to the drivers, which will not be trivial with stuff that needs to talk to graphics cards. This additional layer will need to support all the varieties, meaning that an update to Vulcan will require a new version, as will an update to Direct-X, etc.
Also, this approach is entirely future-blind. What does a chip with a built in FPGA look like to your universal software thing? Does it have to universalize FPGA programming and utilization as well? An algorithm meant for FPGA usage may be shockingly slow if dragged into the CPU and executed. What if the universal software needs random numbers? There's a huge difference in how random numbers can be, and this cannot be virtualized away. If you expose that your numbers are generated by the CPU instead of an exeternal RNG, then the application can refuse to run without secure random numbers, making it not universal. If you abstract that away, then your crypto program may never run the way it needs to- it may be totally useless. What about something further away, like a quantum compute card, or whatever?
> I'm going to risk the inevitable downmod from the rabid hard right and alt-right types by finally thinking that we have maybe another six to nine months before even a majority of Republicans in Congress begin planning to remove this imbecile from office.
Ah, pause your actions, all! Heed and record the March prediction from MightyMartian!
We'll add this to the February prediction of "I honestly think Bannon's days are numbered", the January prediction of "Congress is going to start moving to claw back the Presidency's legislatively enabled executive powers", the December prediction of " a man of Trump's age is unlikely to be seeking a second term" (he registered for 2020 on the evening of inauguration day, so he is, unprecedentedly, the only declared 2020 candidate), and of course the November prediction that "I am so going to enjoy rubbing it into Trump supporter's faces on Wednesday.".
> Everytown for Gun Safety has no interest whatsoever in "gun safety".
No, they're just another bunch of gun grabbing tyrants.
But, the topic isn't about them, and how much they suck. It's about whether it is at all ok for Snapchat to basically try to extort them by asking for cash or threatening to play a countermessage.
It's phrased cleverly enough to avoid any legal issues, probably- they simply mention that the NRA is talking about buying advertisement time- but that is clearly meant as a threat.
Anyway, it seems fucking dirty, right? If they are doing this to one organization, they'll probably do it to more. It's probably a pretty effective technique.
> The IMX6 from qualcom hits all these checkboxes
Like OpenRex? I don't know exactly how you can find good solid open hardware, but I know you pretty much have to turn to ARM for that.
My point is, that activism crap is totally offtopic when a system integrator company comes out and asks what Linux based developers need in a laptop.
"What do you need in an x86 Linux laptop?"
"Obviously, it needs to not be x86, and to use an ARM chip that doesn't exist yet, using software that only partly exists"
SUPER HELPY
This is not a fight to take to Razer. OP should take this crap to AMD or Intel, who are responsible for the current state of ring -3 type affairs.
Under Windows, the keys have an idiotic default function- call up a menu. Which in a full screen app, makes it flip graphic modes, etc. And in a windowed app, defocuses it. For an OS that brags about games though, it sure is nuts that they put "lose the game" right between "fire" and "jump". But under Linux, you've never been as trapped by this crap as you were under Windows, and you can make the meta keys do whatever you want, or nothing at all.
> Intel ME is certain to contains a network-accessible backdoor
I see a lot of talk about this, but I don't see many mitigations that can be done by the average user, or even, for that matter, the exceptional user.
Some ways to PRESUMABLY disable ME have been discussed:
http://hackaday.com/2016/11/28...
But you still have it under there, doing something- this just seems to make it network blind. That's a pretty good start.
What if you don't have like, whatever chip programmer this approach needs, and/or other incompatible hardware?
Is it beneficial to cut off a potential ME backdoor via blocking ports at your (non-x86) router? Which ports would give you the best defense?
Is it beneficial to use a non-mobo based network card (wifi or ethernet), in the hopes that the ME won't be smart enough to monitor that? Aka, are most firmware network stacks all about the network functionality built into the mobo?
Are there any other general mitigations that should be followed?
Basically, what is best practice to mitigate this on modern hardware, given that you are on a piece of hardware that you cannot or will not perform the hardware hackery required to blank some of its pages?
Most of this post also works for AMD if you swap Intel->AMD and ME->PSP.
> A truly free and open-source software laptop... which allows a FOSS BIOS or UEFI replacement, FOSS drivers. No Blobs, or Intel ME.
Fuck off.
Yes, what you say would be perfect. But that is not something that Razer, as a system integrator and builder, gets to pick. There's NO Intel chips without the ME. There's ZERO AMD chips without the PSP, which is the rough equivalent of the ME (and has all the same issues YOU care about that ME does). Razer is trying to build a machine for developers, as they say here, and you are saying "Well, first of all, lets totally avoid x86". Does that sound like something that will sell to x86 developers?
> Journalists, activists, and anyone who must have a secure, trusted computing device
Which will never be built by fucking Razer, and you know it. This is Razor trying to expand from just slapping LEDs on everything. A Razer Linux laptop should have features like "the Meta key should not have a stupid Windows logo on it for some reason" and "the rainbow LEDs should be configurable in the BIOS, and not just via a proprietary configurator written in Java that still manages to only support Windows".
At best, you can argue for open specifications where they could be put, given that it is meant to be able to be used for open source software.
But to solve the issues you are talking about is not the problem of a laptop manufacturer. It represents a deep set of issues embedded up and down the supply chain. Bitch about that. Go grief AMD and ask them to make a chip compatible with libreboot- don't act like Razer is gonna solve this issue, or that they even should try.
> The underlying OS doesn't really matter too much.
Sure it does. With Windows, your keyboard input is sent to Microsoft, to help them, uh, personalize your input experience. Or whatever their reasoning is.
Every time you open notepad, gotta send packets to Microsoft. Gvim on Linux doesn't have this, err, feature. This is a "feature" that not even emacs has!
http://www.wasdkeyboards.com/i...
"Select OS Key" -> Linux Tux
I think it also exists for the other keyboard types they sell.
> It'll be interesting to see if the release of the Nintendo Switch recovers some of this loss.
It won't. More importantly, it can't.
This loss is based on speculation- this is about Gamestop's stock market price. It is going down because people are assuming that the company is more likely to experience hardship as a result of Microsoft's latest whatevermajig.
The Switch, on the other hand, is a known quantity, and everyone is assuming it will sell out immediately, because Nintendo never makes enough for their demand. So if Gamestop sells every Switch that they see, that's what everyone is assuming. And it isn't like Gamestop has some great claim on the Switch as opposed to say, Best Buy, Wal*mart, Amazon, Toys Backwards "R" Us, etc. The Switch games could outsell predictions, and that would help the whole retail video game sector, but it is unlikely to be a huge driver, given that it is just one of many categories of products sold.
The Switch could be a success, or a moderate failure, and not impact Gamestop's stock price much- or their bottom line, really.
Keep in mind that stock prices at best only represent a best guess situation anyway.
> Games have notoriously been single threaded for ever, because it's a lot easier to program a linear algorithm and keep memory use clean.
Some things games have to do are fundamentally single threaded, but you are correct: it's easier to program a single thread, and often the gain from another thread doesn't help much. 3D games are a little different, because much of the CPU tasking involves doing stuff so that data can be pushed to the graphics card. Those scale VERY well with extra cores, but only if coded that way.
An example is the MMO Star Wars: The Old Republic. In any area where there is not many players, the CPU has almost nothing to do. It continuously funnels requests for frames to the graphics card, which goes totally bonkers rendering hundreds of frames per second, and spinning its fan like crazy (there's a vsync option, should you be looking for a solution to this issue, and also be running fullscreen). In an area where there's a ton of players, your frame rate drops below 60 fps, and sometimes even below 30 fps, and the graphics card fan is silent. Check out the processor status, and you see the CPU dance:
https://www.youtube.com/watch?...
And a bit of investigation reveals that the process is barely multithreaded at all.
Meanwhile, other games don't have this issue: they divest that logic across the cores, and the graphics card can be fully tasked (ideally intelligently so), giving you a good framerate consistently, with your GPU fan starting up if the game is actually rendering something hard.
But again, that requires those games be programmed that way. And more are being programmed that way today. Mostly, game developers have been happy to take the much simpler single threaded approach, which reduces development costs, and if you have to support a bunch of dual core chips because a decent chunk of your customers have those, why spend your time worrying about the extra cores most chips have? That's not necessarily how all future development will go, however, especially if, as is being made obvious, that adding more cores is a lot more reasonable than adding a little bit of IPC and clock.
> No, the answer is that single threaded is nearly always more important than multi-threaded, because you are doing single threaded tasks about 99% of the time.
The answer is nowhere near that simple. If your single threaded task is any manner of I/O bound- disk, network, or memory, then you can't speed it up any further with a faster CPU, on clock or IPC. If PARTS of it are bound in those ways, then a faster processor will help, but not linearly.
But in general, if you had a choice between a 4 GHz 8 core processor and an 8 GHz 4 core processor, you'd take the faster chip. But that has NEVER been the comparison, and that's why YOUR USE CASE matters, and why single threaded performance is not always the answer. In the top end desktop useage, you'll usually pick between something like the i7-6900K (Intel's 8 core desktop offering, stable up to 4.3 GHz, a Broadwell piece released middle of last year) and the i7-7700K (Intel's very latest 4 core desktop offering, some of which are stable up to 5 GHz, a Kabylake piece two generations advanced from Broadwell). And when these are benchmarked, you see that CPU bound tasks that are single threaded are in fact a bit faster on the Kabylake, which has both slightly improved instructions per clock over the broadwell piece, and a faster clock speed, but that anything that can make use of the cores is a LOT faster on the Broadwell chip.
More relevantly, you get to make this tradeoff at many prices, and the reason you are normally going to recommend the higher singlethreaded performance is because the piece with the more core, while way hella better in multithreaded parts, usually costs more. Doubling cores doesn't double performance in multithreaded, but it isn't too far off in some cases. Meanwhile, a 20% increase in clock speed normally gets you almost 20% more performance on single threaded.
AMD's chips are coming in at prices that are competitive with the 4 core desktop chip, while offering performance that competes with the 8 core desktop/enthusiast pieces. That's why this is important.
And why your use case matters.
And your use case is probably going to favor more cores, going forward. Only you know better for you, of course, but as a general recommendation it is worth pointing out.
> $500 R7 1800X vs $340 i7 7700k.
The 1800X is like 8 cores to the 7700K's 4 cores. The 7700K, having half the cores, will presumably do better on single threaded tasks, such as the benchmarks in question. Future code, especially that which makes requests to the GPU in a multithreaded fashion, will perform better with more damned cores. For single threaded (or basically that), the 7700K also blows away Intel's 6950X, their top desktop CPU offering with 10 cores.
A better comparison per price point would be the 1700X or 1700 to the 7700K. Again, you find that the 8 core chip blows away the 4 core chip on multiprocessing, with less amazing results from a single thread.
There's a ton of applications that scale well with cores, and games will begin to do so more in the future. There will always be tasks that can't be parallelized, but the question is, when do they matter versus the ones that can? The question of cores versus speed per dollar is about as old as CPUs, and the answer is always "what is your use case".
Replication doesn't happen on its own. If it did, we wouldn't have cells, and hell, viruses wouldn't need them to replicate either.
The question you are probably asking, that I don't know the answer to, is "what are the odds that a given one of these strands contains instructions that, when put in some kind of cell, would end up creating a virus". I'd imagine the odds would be really steep... but hey, you'd only need one part to behave like that, right?
> Still, it's notable that bitcoin has (at least temporally) surpassed the price of gold.
Bullshit, it has not.
There's a cap of 21 million bitcoins. Of this, over three quarters have already been mined. It is supposed to get progressively harder to mine bitcoins, with the intention that the huge numbers of bitcoins that are sitting fallow will eventually appreciate in value, that it will still be worth mining them even as they get harder, etc. Regardless of your views on this, or cryptocurrencies: there's only 21 million bitcoins total.
1 bitcoin is one twenty-millionth of all bitcoins. It is about .000005% of the total blob of bitcoins that will ever be. .000005% of all the gold mined to date- which is definitely not all the gold ever- is around 300 ounces of gold. And that's a very low estimate for the total gold available- some sources have it at over ten times that in available gold. The fact that no one has it pinned down to at least a solid order of magnitude is depressing, but the point is that even the low estimates, the percentage of one bitcoin compared to all the bitcoin, versus that same percentage of gold compared to all the gold, is nowhere close in bitcoins favor.