There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running.
Well except that you make way too many assumptions. Like EFI will intrinsically (magically) know how all bootable devices past, present, and future work. And it has, and can maintain complete control over all known and unknown interfaces to those devices at all times, and scrub all the calls to those interfaces to prevent any attempts to write to the boot sector. Also, it would magically retain that control whether attached or unattached to the machine (USB stick, Sata Dock). Many of those are either impossible, limiting, and/or silly.
And any of those would cause a problem with your solution. None of those are new vectors. Have we not learned anything in the past 30+ years of computing? Apparently you haven't.
UEFI doesn't solve the problems that it's supposed to either.
Oh really?
UEFI devices are no longer trying to cram all their ROMS into a shared 384k area. UEFI devices have a common API so that they can be configured all through a common interface (No more hit control-I/N/Z/Q during boot to configure that specific device). UEFI systems *CAN* (Not required) to have a GUI interface, full help system, ability to update itself from a secure (relatively) environment. UEFI systems *CAN* (not required) be assured that the OS gets control first rather than some unsecured (rootkit) gets control before the OS does. UEFI systems *CAN* (if written that way) boot faster by initializing multiple devices concurrently rather than serially.
Seems UEFI does exactly what it is supposed to be doing. Maybe it's not doing what you want in an ideal world, but it does solve the problems it was designed to. And it works today. Considering I'm using it right now, and it did solve all those problems for me, which traditional BIOSes could not either because of technical limitations of BIOS itself, or because of the limited space available to it.
I have no problem supporting FSF in this area. But, they aren't advocating what the article on slashdot says (Specifically the title). They aren't rallying against UEFI, nor even Secure Boot. Just making sure that end users can disable Secure Boot if they want.
BIOS is not fine. BIOS is a piece of shit that should have been thrown away 10 years ago.
Have you ever tried installing multiple high performance devices into a motherboard that still uses BIOS? Didn't think so. BIOS is limited to 16-bit, and addressing less than 1MB of RAM, and devices are forced into 384K of that space (Boot ROM/Required Memory mapping). Of course there are other issues as well, like being single threaded, not being able to initialize multiple devices in parallel, etc etc.
BIOS was acceptable when we had the 8086 and 640k was more than enough for everyone. We aren't in that world anymore.
I have to agree with the majority of what you've said. I'm not using my desktop any less than I have in the past, but I AM upgrading less often, and I don't see myself upgrading again in the next 3-5 years where I was always upgrading the guts of my system every 18 months, and my video card ever 12 months.
Now I've got a 6-core hyperthreaded system running at 4GHz, 64GB of RAM, 2 128GB SSDs in RAID-0 for boot/operating system, and 30TB of disk space in a RAID-6 for applications and media. Most of which I don't really need, but I wanted because I could. I'm still using my 2+ year old NVidia 580 video card, and I have no intention of upgrading it any time soon. There just isn't a compelling reason to. My monitor is now 8 years old, but it's a 1920x1200 LCD, so unless there is a compelling reason to change it or it dies, I won't be changing that out any time soon either.
Most of my friends are in the exact same boat. They used to upgrade like clockwork, but are no longer doing so because there simply isn't a reason to. Not for home use anyway.
WP was the worst. It was slow, both the Windows and DOS versions. It's font support was absolutely terrible. Then there were tons of incompatibilities with printer drivers. Layout of complex pages in Word Perfect (wrapping around images, etc) was difficult. We TRIED to stay a WP shop, but it didn't take that long after we allowed our documentation and marketing departments to switch to Word that we decided to switch the entire company over. Long gone were the printer issues, the speed issues, and the font issues. I heard that WP finally solved most of those a couple years later... A couple years too late.
I doubt this would classify as blackmail because there is no "threat". You ARE on the list. They aren't charging you or else they will put you on the list. It's already been done. Now there may be something else illegal about it, but I doubt it would fall under blackmail.
Unfortunately, it IS effective. If you are really that concerned about it, then pay the fee to get a fixed IP, or relay your mail to a server than has a fixed IP. It's not expensive.
OK, let's take a long step back. The original post I made was about why you would want a central market place, and I responded to that question. I didn't take it as a specific reference to Microsoft's Store, either in it's current form or any form it may take in the future, but as a generic answer as to why one would be beneficial. It is on a generic level the equivalent of a linux software repository. Arguing that having hooks in the OS for a software repository/store isn't a feature is silly. You may not use it, nor like it, but that doesn't mean the some (I would argue most) users would like it.
Now from that, every response wants to take a look and nit pick about specific implementations of that. While I tend to think that the Microsoft Store will be less heavy handed than say Apple's in regards to what they will and won't approve to put in the store (I haven't seen anything that is restricted, but I haven't actively looked). Regardless of that, there is nothing keeping users from installing whatever they want from outside of the store environment on Windows 8 Pro machines -- so again, if you don't like it, don't use it. Find your own software and install it. However, I believe having one place to which you can find most/all of your applications, and be fairly sure that it isn't just some malicious trojan infected piece of software AND you have one central place to check for updates (rather than 200 different background "update checkers") and actually do the updates (one at a time or in batch), is a good thing. You may disagree.
Also, I'm not right out of college, I don't work at my dad's company, but I do occasionally berate clients when they say what they do, and I do sometimes disagree with employees under me, work with me, or I work for -- it is always on a professional level. I don't know everything, and neither do they -- if we disagree it is either because we have different philosophies, or are on different levels of experience and eventually I or they will learn. Often our discussions are more about learning the why and transferring knowledge from someone who is more experienced in a subject to one that is not than trying to prove who is right to brag. We are all pretty solid headed and understand we aren't all experts in everything, but we always try to learn from those who have more experience than we do.
Yes, you have twice the number of registers in 64-bit, however, there are some performance penalties for using them (prefix ops), and I'm pretty sure that the register renaming that is done really makes that a rather moot point except for the prefix op penalty still applies if you try it. You are going to find a mixed bag of performance characteristics trying to use them unless you are really really careful, and most compilers aren't, and most apps aren't going to hand code assembler to get it right.
Secondly, depending on the use of your ints under 64-bit, either you are extending them to 64-bitness in which case, they will suffer a performance penalty through memory bandwidth (assuming of course, you need to access a serial number of them that extends beyond the line), or you are going to keep them 32-bit, in which case you suffer a performance penalty in the form of a prefix iop in most cases. Now, you usually can offset those performance hits by various means (doing 64-bit arithmatic instead of 2 32-bits, making use of the additional 64-bit registers where the performance gain is greater than the performance hit in using them, etc), but not always.
As I said 5 posts up... 64-bit isn't just simply faster. It's sometimes/often/usually faster depending on what you do, but it is ALWAYS larger in memory and disk space usage, and plays less well with other applications (Cache size overruns caused by the larger size -- and this is for all the caches -- L0 uop cache, L1 memory cache, L2, etc).
Plus your benchmarks mean nothing with FireFox -> the people behind the builds have put that much more effort into optimizing it for 32-bit over 64-bit. It's like complaining how much the 64-bit version of Windows XP sucks compared to the 32-bit version -> there's almost no support for the 64-bit version, and it will remain as such until the Mozilla group stops dragging its heels.
Here you seem to agree, 64-bit isn't just simply faster. While you seem to contend that given the right amount of optimization you CAN make it always faster, it isn't just simple, and I contend that while in most cases it may be, it isn't always true. Now, unless you feel rolling every possible combination of ops and memory access patterns, you aren't going to be able to prove your case, while if you actually read Intel's own documentation on 64-bit performance tuning, you will see that they agree with me.
Mr Buzzword doesnt know what he is talking about...
I'm glad you admit you don't know what you are talking about. I wish more people who didn't know would admit it right up front like you did.
The fact that the pointers use an extra 4 bytes is a negligible detail because the L1 caches are huge in relation to those 4 bytes. You would need a very large amount of pointers within the cache to have any sort of measurable effect, so large that following even small percentages of them (why are they in the caches if you arent using them?) will always cause significant L1 thrashing.
The fact that pointers (and anything dealing with size or offset) uses DOUBLE the size, and isn't negligible. It's effectively halving the size of the caches (total size, line size) in terms of the number of pointers/ints that they can contain.
But an even harder argument for you to try to refute is that Intel isnt stupid. The cache parameters (total size, line size, number of sets, for each level of cache) are optimized for 64-bit computing on their 64-bit processors. Intel didnt choose a 64 byte L1 line size willy-nilly. Intel didn't choose 32KB of L1 data willy-nilly. Intel didnt choose 8-way set associativity for their L1 willy-nilly.
I'm not going to refute that, nor is that directly related. However, as a side note that I don't want to get tied up in, I will point out that even Intel isn't flawless in their execution. For example, see their assumption about netburst being scalable to 10GHz and the fallout from that not being correct.
Now, after you spend a day figuring out what line sizes and set associativity are, and what impact they have, dont bother replying.. because by that point it will just be desperation on your part.
You assume too much, based on too little. You don't know me, yet you assume you know what I know. That's a pretty neat trick, and you would be wrong. Let me clarify. I've been performance tuning before you were likely born (based on the average age of the slashdot readers). I've written my own kernels, and I was even in talks with a major company to help them write theirs (Yes, you've definitely heard of them, in fact I'd be surprised if they weren't mentioned at least 10 times in this thread) as they copied/stole some of my concepts for an earlier release of their OS.
That said, I'll leave you world of misconceptions on hypothetical performance tuning and bring you into reality: Firefox 32-bit ON MY MACHINE, scores 12784 on the V8 benchmark located here: http://v8.googlecode.com/svn/data/benchmarks/v7/run.html Firefox 64-bit ON MY MACHINE, scores 9874 on the same V8 benchmark.
64-bit isn't just simply faster. It's sometimes/often/usually faster depending on what you do, but it is ALWAYS larger in memory and disk space usage, and plays less well with other applications (Cache size overruns caused by the larger size).
I don't see why not. Windows XP 64 supported 8 (DOS)/16 (DOS/Win)/32 (DOS/Win)/64 (Win) bit apps. They only recently dropped support for 16-bit Windows Apps.
That is a bit of a stretch. If that were true, people would have problems with everything from any "10 foot" interface to ATM machines to option screens to not remembering where they are going once they step into a car.
Besides, the study showed a slight, but measurable delay in answering, not total amnesia.
So you are concerned that if you are using a laptop that has a start screen while walking through a doorway, some people might take a bit longer to resume what they ate doing?
Somehow, I don't think that is the typical use case.
Slashdot Mirror
There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running.
Well except that you make way too many assumptions. Like EFI will intrinsically (magically) know how all bootable devices past, present, and future work. And it has, and can maintain complete control over all known and unknown interfaces to those devices at all times, and scrub all the calls to those interfaces to prevent any attempts to write to the boot sector. Also, it would magically retain that control whether attached or unattached to the machine (USB stick, Sata Dock). Many of those are either impossible, limiting, and/or silly.
And any of those would cause a problem with your solution. None of those are new vectors. Have we not learned anything in the past 30+ years of computing? Apparently you haven't.
UEFI doesn't solve the problems that it's supposed to either.
Oh really?
UEFI devices are no longer trying to cram all their ROMS into a shared 384k area.
UEFI devices have a common API so that they can be configured all through a common interface (No more hit control-I/N/Z/Q during boot to configure that specific device).
UEFI systems *CAN* (Not required) to have a GUI interface, full help system, ability to update itself from a secure (relatively) environment.
UEFI systems *CAN* (not required) be assured that the OS gets control first rather than some unsecured (rootkit) gets control before the OS does.
UEFI systems *CAN* (if written that way) boot faster by initializing multiple devices concurrently rather than serially.
Seems UEFI does exactly what it is supposed to be doing. Maybe it's not doing what you want in an ideal world, but it does solve the problems it was designed to. And it works today. Considering I'm using it right now, and it did solve all those problems for me, which traditional BIOSes could not either because of technical limitations of BIOS itself, or because of the limited space available to it.
I have no problem supporting FSF in this area. But, they aren't advocating what the article on slashdot says (Specifically the title). They aren't rallying against UEFI, nor even Secure Boot. Just making sure that end users can disable Secure Boot if they want.
A story made from a non-story. Nice.
BIOS is not fine. BIOS is a piece of shit that should have been thrown away 10 years ago.
Have you ever tried installing multiple high performance devices into a motherboard that still uses BIOS? Didn't think so. BIOS is limited to 16-bit, and addressing less than 1MB of RAM, and devices are forced into 384K of that space (Boot ROM/Required Memory mapping). Of course there are other issues as well, like being single threaded, not being able to initialize multiple devices in parallel, etc etc.
BIOS was acceptable when we had the 8086 and 640k was more than enough for everyone. We aren't in that world anymore.
As for OS's that won't run with UEFI disabled. I have no use for them.
I think you meant SecureBoot. Disabling UEFI would be silly.
i3, i5, i7 is the most important. The processor model is pretty much irrelevant for most people. Next is the speed.
If you really want to compare systems, we already have that. It's called the Windows Experience Score. Use it. It's pretty simple.
Wow, an AC crackpot, how unusual.
I have to agree with the majority of what you've said. I'm not using my desktop any less than I have in the past, but I AM upgrading less often, and I don't see myself upgrading again in the next 3-5 years where I was always upgrading the guts of my system every 18 months, and my video card ever 12 months.
Now I've got a 6-core hyperthreaded system running at 4GHz, 64GB of RAM, 2 128GB SSDs in RAID-0 for boot/operating system, and 30TB of disk space in a RAID-6 for applications and media. Most of which I don't really need, but I wanted because I could. I'm still using my 2+ year old NVidia 580 video card, and I have no intention of upgrading it any time soon. There just isn't a compelling reason to. My monitor is now 8 years old, but it's a 1920x1200 LCD, so unless there is a compelling reason to change it or it dies, I won't be changing that out any time soon either.
Most of my friends are in the exact same boat. They used to upgrade like clockwork, but are no longer doing so because there simply isn't a reason to. Not for home use anyway.
WP was the worst. It was slow, both the Windows and DOS versions. It's font support was absolutely terrible. Then there were tons of incompatibilities with printer drivers. Layout of complex pages in Word Perfect (wrapping around images, etc) was difficult. We TRIED to stay a WP shop, but it didn't take that long after we allowed our documentation and marketing departments to switch to Word that we decided to switch the entire company over. Long gone were the printer issues, the speed issues, and the font issues. I heard that WP finally solved most of those a couple years later... A couple years too late.
But it doesn't fit that description, because there is no threat to disclose... they ARE already disclosing.
I doubt this would classify as blackmail because there is no "threat". You ARE on the list. They aren't charging you or else they will put you on the list. It's already been done. Now there may be something else illegal about it, but I doubt it would fall under blackmail.
Unfortunately, it IS effective. If you are really that concerned about it, then pay the fee to get a fixed IP, or relay your mail to a server than has a fixed IP. It's not expensive.
OK, let's take a long step back. The original post I made was about why you would want a central market place, and I responded to that question. I didn't take it as a specific reference to Microsoft's Store, either in it's current form or any form it may take in the future, but as a generic answer as to why one would be beneficial. It is on a generic level the equivalent of a linux software repository. Arguing that having hooks in the OS for a software repository/store isn't a feature is silly. You may not use it, nor like it, but that doesn't mean the some (I would argue most) users would like it.
Now from that, every response wants to take a look and nit pick about specific implementations of that. While I tend to think that the Microsoft Store will be less heavy handed than say Apple's in regards to what they will and won't approve to put in the store (I haven't seen anything that is restricted, but I haven't actively looked). Regardless of that, there is nothing keeping users from installing whatever they want from outside of the store environment on Windows 8 Pro machines -- so again, if you don't like it, don't use it. Find your own software and install it. However, I believe having one place to which you can find most/all of your applications, and be fairly sure that it isn't just some malicious trojan infected piece of software AND you have one central place to check for updates (rather than 200 different background "update checkers") and actually do the updates (one at a time or in batch), is a good thing. You may disagree.
Also, I'm not right out of college, I don't work at my dad's company, but I do occasionally berate clients when they say what they do, and I do sometimes disagree with employees under me, work with me, or I work for -- it is always on a professional level. I don't know everything, and neither do they -- if we disagree it is either because we have different philosophies, or are on different levels of experience and eventually I or they will learn. Often our discussions are more about learning the why and transferring knowledge from someone who is more experienced in a subject to one that is not than trying to prove who is right to brag. We are all pretty solid headed and understand we aren't all experts in everything, but we always try to learn from those who have more experience than we do.
Yes, you have twice the number of registers in 64-bit, however, there are some performance penalties for using them (prefix ops), and I'm pretty sure that the register renaming that is done really makes that a rather moot point except for the prefix op penalty still applies if you try it. You are going to find a mixed bag of performance characteristics trying to use them unless you are really really careful, and most compilers aren't, and most apps aren't going to hand code assembler to get it right.
Secondly, depending on the use of your ints under 64-bit, either you are extending them to 64-bitness in which case, they will suffer a performance penalty through memory bandwidth (assuming of course, you need to access a serial number of them that extends beyond the line), or you are going to keep them 32-bit, in which case you suffer a performance penalty in the form of a prefix iop in most cases. Now, you usually can offset those performance hits by various means (doing 64-bit arithmatic instead of 2 32-bits, making use of the additional 64-bit registers where the performance gain is greater than the performance hit in using them, etc), but not always.
As I said 5 posts up... 64-bit isn't just simply faster. It's sometimes/often/usually faster depending on what you do, but it is ALWAYS larger in memory and disk space usage, and plays less well with other applications (Cache size overruns caused by the larger size -- and this is for all the caches -- L0 uop cache, L1 memory cache, L2, etc).
Plus your benchmarks mean nothing with FireFox -> the people behind the builds have put that much more effort into optimizing it for 32-bit over 64-bit. It's like complaining how much the 64-bit version of Windows XP sucks compared to the 32-bit version -> there's almost no support for the 64-bit version, and it will remain as such until the Mozilla group stops dragging its heels.
Here you seem to agree, 64-bit isn't just simply faster. While you seem to contend that given the right amount of optimization you CAN make it always faster, it isn't just simple, and I contend that while in most cases it may be, it isn't always true. Now, unless you feel rolling every possible combination of ops and memory access patterns, you aren't going to be able to prove your case, while if you actually read Intel's own documentation on 64-bit performance tuning, you will see that they agree with me.
You would be incorrect. Windows 8 Pro runs any old executable that ran on Windows 7, you don't need to recompile or anything.
On the other hand, with humans, each human learns how to correctly deal with situations. With computer drivers, they ALL learn from one mistake.
Perhaps, but a 9 YO that is paying attention is probably a better driver than most people out there.
Mr Buzzword doesnt know what he is talking about...
I'm glad you admit you don't know what you are talking about. I wish more people who didn't know would admit it right up front like you did.
The fact that the pointers use an extra 4 bytes is a negligible detail because the L1 caches are huge in relation to those 4 bytes. You would need a very large amount of pointers within the cache to have any sort of measurable effect, so large that following even small percentages of them (why are they in the caches if you arent using them?) will always cause significant L1 thrashing.
The fact that pointers (and anything dealing with size or offset) uses DOUBLE the size, and isn't negligible. It's effectively halving the size of the caches (total size, line size) in terms of the number of pointers/ints that they can contain.
But an even harder argument for you to try to refute is that Intel isnt stupid. The cache parameters (total size, line size, number of sets, for each level of cache) are optimized for 64-bit computing on their 64-bit processors. Intel didnt choose a 64 byte L1 line size willy-nilly. Intel didn't choose 32KB of L1 data willy-nilly. Intel didnt choose 8-way set associativity for their L1 willy-nilly.
I'm not going to refute that, nor is that directly related. However, as a side note that I don't want to get tied up in, I will point out that even Intel isn't flawless in their execution. For example, see their assumption about netburst being scalable to 10GHz and the fallout from that not being correct.
Now, after you spend a day figuring out what line sizes and set associativity are, and what impact they have, dont bother replying.. because by that point it will just be desperation on your part.
You assume too much, based on too little. You don't know me, yet you assume you know what I know. That's a pretty neat trick, and you would be wrong. Let me clarify. I've been performance tuning before you were likely born (based on the average age of the slashdot readers). I've written my own kernels, and I was even in talks with a major company to help them write theirs (Yes, you've definitely heard of them, in fact I'd be surprised if they weren't mentioned at least 10 times in this thread) as they copied/stole some of my concepts for an earlier release of their OS.
That said, I'll leave you world of misconceptions on hypothetical performance tuning and bring you into reality:
Firefox 32-bit ON MY MACHINE, scores 12784 on the V8 benchmark located here: http://v8.googlecode.com/svn/data/benchmarks/v7/run.html
Firefox 64-bit ON MY MACHINE, scores 9874 on the same V8 benchmark.
Obviously Lucy, you've got some 'spaining to do.
Umm... No, it does not.
I stand corrected, you did need to run 16-bit Windows apps/Dos apps inside Virtual PC to get them to run.
64-bit isn't just simply faster. It's sometimes/often/usually faster depending on what you do, but it is ALWAYS larger in memory and disk space usage, and plays less well with other applications (Cache size overruns caused by the larger size).
I don't see why not. Windows XP 64 supported 8 (DOS)/16 (DOS/Win)/32 (DOS/Win)/64 (Win) bit apps. They only recently dropped support for 16-bit Windows Apps.
That, after all, is a job for Excel
FTFY
That is a bit of a stretch. If that were true, people would have problems with everything from any "10 foot" interface to ATM machines to option screens to not remembering where they are going once they step into a car.
Besides, the study showed a slight, but measurable delay in answering, not total amnesia.
So you are concerned that if you are using a laptop that has a start screen while walking through a doorway, some people might take a bit longer to resume what they ate doing?
Somehow, I don't think that is the typical use case.