You don't quite have all the sources, then - you don't have the private key, without which you can not generate the signature, which is a part of the binary. The GPL requires that you be able to modify the sources and be able to produce the binaries. The original signature file is not "source", and they haven't included all of the source needed to produce it.
In the example you give of the signed.tgz file, I would argue that the signature is not a part of the binary - it is accompanying the binary, but is never referenced, thus there's no requirement to be able to reproduce it.
In the case of the TiVo loader, given that it requires the signature, and given that it is NOT distributed independently of the GPL binary, it is NOT a "mere aggregation". One could even argue that such use means that they should be distributing the sources to the boot loader as well.
And a LOT of programs don't get that rule right. In fact, a lot of programs didn't get that rule right even though 2000 would have been correct if they simply used the every-four-year rule and no other. There are still programs running that don't even get it right every FOUR years, because it happens so infrequently that people just live with it screwing up. So now you expect that a to-be-specified-in-the-future date to add an extra hour to a day is going to be put into programs, and TESTED, and actually work correctly? When the only real way to test it is to flip the switch telling all programs the world over to do it? The very first time?
I didn't ask "how do we test it?", I asked "when do we test it?", when no one is going to start even coding for it for 495 years. Y2K only had to deal with a legacy of around 40 years of people ignoring what might happen in 2000.
Having a leap second every year or so is an excellent way to weed out stupid programs that can't handle it. Having something happen only once every 500 years is asking for a disaster every 500 years. Right after Y2K, lots of programmers just said "well, at least that's done with, now all I have to do is hardcode in 2000 instead of 1900, and I don't have to worry about it - after all, this program can't possibly still be running in 3000!
a) the leap-year rule only goes out a few terms; it's still inaccurate over the really long term; b) in less than that really long term, the difference of a second every year doesn't make a difference; c) the period of the Earth's orbit around the Sun is also changing slowly, so no formula is going to be exact anyway.
That's not a leap hour. With the switch to DST, the time stays the same, but the representation is dependent on the time zone, and the time zone changes. If you aren't paying attention to the time zone, there is a discontinuity in the flow of hours, either time jumping forward by one hour or jumping back by one hour. Jumping back by one hour can be particularly bad when date order is important. Thus, any program that cares about the current "local time" uses standard routines and doesn't do any timekeeping based on the "local time hour".
With a leap hour, the time doesn't change, and the timezone doesn't change. You simply get an extra hour at the end of the day. Time goes from 23:59 to 24:00 to 24:01 to 24:59 to 00:00 the next day. It is nothing at all like the shift between standard and DST. However, it is still the case that the "number of seconds since Jan 1 1970" doesn't change - the shift with a leap second or leap hour is still only with the local representation of time, except that it changes it for all time zones at the same time.
True, asking what the minute is going to be in exactly 315532800 seconds from now is uncertain. So what? Anything that cares is going to simply store 315532800, not "10 years". If you want to schedule something to occur on July 30, 2015 at 11:17PM CDT, then presumably you'd want it to occur taking into account leap seconds as of that time (and any changes to Daylight Savings Time, as well). Nothing hard about that.
That's what I said - it is based off of "Atomic Time", which does not have leap seconds added. It then includes a field with the total offset from Atomic Time to UCT, i.e. the cumulative number of leap seconds since whatever epoch it is using. A GPS unit will add that value in when displaying local time, but the uncorrected value is used for all calculations.
No, the formula for leap years is based on the period of the Earth's rotation around the sun not being 365 days long. Leap seconds are based on variations in the Earth's rotation around its axis such that the day is not exactly 86,400 seconds. Completely independent, solving completely different problems (in one, the seasons drift, in the other noon drifts).
But the hour WON'T "jump forward or backward an hour". You'll either have a 23-hour or 25-hour day, plus it will only happen once every 500 years or so. When are you going to test it? When are you going to start putting it into programs? And you thought that programmers storing only 2 digits for the year were stupid and shortsighted...
The whole thing is a crock. Software that hardcodes in conversions between days/hours/minutes/seconds, AND needs to be so accurate to the rest of the world that it has to account for leap seconds, must be rewritten to use a standard library routine. Internally, it should simply keep a seconds counter, and base all intervals off of that. There's no excuse for doing it wrong, and code that does do it wrong should be rewritten if it is critical.
More likely, 500 years from now we won't be using the rotation of the Earth as a time base, as a majority of people will be elsewhere.
Regardless, I think it's time that software that can't handle leap seconds be updated - piss poor programming isn't an excuse for glossing over an inconvenience of nature, especially when the proper programming is already easy to do. Leap seconds shouldn't affect an internal clock, so anything doing interval timing should be unaffected. The only thing that should really care about leap seconds is something that is breaking things down into days/hours/minutes/seconds - primarily, for display purposes - or something that actually needs leap seconds, such as astronomy calculations (in which case, eliminating leap seconds for that application would be pointless). For display purposes, why should it matter if you get "60" for the seconds field? Or, more to the point, virtually all such systems have such inaccurate clocks, they shouldn't need to care about leap seconds between times that the time is manually reset. If they're using a GPS receiver as a time base, why not just make a modified receiver that doesn't report leap seconds? If for some reason the displayed time has to be in synch with "real time", make the clock run marginally fast or slow on the day that one occurs, for those few critical systems that somehow have a problem with it? GPS already runs off of "atomic time", with the total number of seconds offset to get to UTC (i.e. total number of leap seconds). Some GPS units actually use that value to figure out what the correct date is (since the weeks field wraps), based on an approximation of the number of leap seconds/year to expect.
The future will think us just as stupid and short-sighted as the people who assumed their programs wouldn't still be around beyond 19xx. Sure, virtually all programs TODAY won't be running in 500 years (though i wouldn't bet on NONE), but people will continue writing programs that won't support a "leap hour" (and the standards bodies won't even get around defining how to handle a leap hour until 3 years before it is to go into effect), and then EVERYTHING will die, or need to be shut down for an hour, when it becomes necessary. Better to have a leap second that occurs every year or two so that people don't get too complacent. There are systems that need to be shut down for the switch to/from DST, and systems that don't properly do leap year, or Feb 29. Why don't we eliminate leap years and DST so that those systems don't break?
Another alternative, just redefine the standard time zones to drift by a minute or so every ten years. Since the timezone file will need to be updated annually to accommodate idiots changing when DST is in effect anyway, it won't be much of a burden...
I thought they were changing the rating of the CURRENT version to AO, sending out stickers to retailers who want to continue selling stock-in-hand, and releasing the modified M-rated version.
I've always thought that the best way to actually eliminate something is to make it legal to be a consumer, illegal to be a provider (or the other way around). Thus, make using drugs legal, but selling or producing drugs remains illegal. I guess Microsoft finally figure out the same thing.
And, of course, you can still experience PLATO today at http://cyber1.org/, TERM-talk, pnotes, notesfiles, avatar and empire and, well, not everything, but lots of it!
e-mail almost always takes less than a couple seconds to be delivered across the Internet, and is practically instantaneous when sent to a local server. The problem is client programs not being notified, not that e-mail takes "too long", and part of that problem is POP. IMAP supports client notification, are there any IMAP servers which do that? Do any IMAP clients enable it?
I don't have a cell phone, but I can see that sending a text message would be much lower "attention overhead" than a phone call. With the phone call, you have to let it ring, wait for them to answer, ask you question, wait for them to answer, and go through a handshaking protocol ("hi, I just wanted to ask you a quick question"; "thanks, I'll talk to you later, bye"), and the other person has to be interrupted and wait for your question, then immediately take the time to find the answer and communicate it (or endure more overhead by having to call back later).
Actually, it is only poor implementations of e-mail that make it less immediate than IM (multi-user "chat" is different). Back in the '70s/'80s, on PLATO, we used TERM-talk (one-on-one typing to each other, even more immediate than IM - see "talk" on Unix systems - each person gets a line and what you type shows up immediately). We also had "e-mail", "newsgroups" and "chatrooms". We used Personal Notes (e-mail) the way people use IM now, because TERM-talk was exclusive - you could only be talking to one person at a time. pnotes notified you immediately when you had a message, so people would carry on near-real-time conversations with one or two lines per note. If you were gone, it was available when you got back. This was often done while also reading notesfiles, you could switch between the two fairly quickly without losing your place.
It really puzzled me when people started complaining about e-mail being "too slow", and that's why they used instant messaging, until I realized most people were using a POP mail reader or equivalent that only checked once every 5 minutes, and I was used to PLATO pnotes and Unix mail with "biff y". IMAP has a method where the server can notify the client immediately when new mail has arrived, but most servers don't seem to implement it.
Given that, I can see why "youngsters" would prefer IM - they're using it for socializing, not for doing "important work". IM is sometimes used for "important work", but almost always just as a priority notification, not for significant information transfer.
Are there any source code control systems that do what the old CDC modify program did (from at least as long ago as the '70s), where each line is identified, and a mod identifies the line(s) to be changed or moved? If the line is moved, it retains its identity, if it is modified it gets a new identity?
Darcs and similar models looks similar to the way modify was used. You had "modsets", which identified the list of mods to be applied and the order to apply them. If you had conflicting mods, you would create additional mods to fix the problem (including a directive "yank" to remove an already applied mod). You could include other modsets. You'd have a main line, and modsets for alternate tracks, alternate environments, experimental versions, etc. The main line would have mods "applied" on a regular basis, at which point active modsets would be updated to take into account new changes where necessary.
Darcs looks like it does some of those modifications to mods automatically. I'll have to look into it.
Your public key has to be signed by a valid key belonging to "The Trusted Computing Authority" or whatever it will be. Barring major breakthroughs in quantum computing or other means of doing prime factorization, the only way to break that would be physical theft or espionage. You can be pretty sure that security for those keys, and the process where they generate the key signature and burn it into each individual chip, will be extremely high. After all, if someone manages to get one of those keys, all processors that are validated using it will become non-trusted when the key gets revoked.
Could you noodle the private key out of an individual processor? Possibly - power attacks, timing attacks, physical attacks are all possible, but it remains to be seen if they will be effective. There are countermeasures for all of those. You wouldn't be able to release a broken private key, though - it will be revoked as soon as it becomes known that multiple systems are using it.
It will probably be easier to crack an individual work (software or content) through physical means, but "trusted systems" will be hardened against that as well (all "protected" content must not be exposed except between "trusted components" that have been authenticated). Finding one component of the chain which has a flaw might be possible, and once you've done that, you might be able to interfere with the authentication process (add in a new "trusted signing key", for example). That still won't get you on the Internet. Part of the signature of a key will certainly include what type of hardware it is, so breaking a sound chip won't let you pretend to be a memory controller or CPU or RAM chip.
You'll have to be a big vendor to get your application signed as trusted - if someone manages to sneak an emulator Easter Egg into it, the application will be revoked and users will be forced to upgrade immediately. Good luck getting an emulator into the next version.
I agree that the whole process is going to be complex enough that flaws are inevitable, either in the software or in the hardware, and cracked content will become available - but it will up the effort required to crack something enormously, and up the stakes as well. Possession of any of the equipment or keys necessary will be illegal. Currently, all you need is a debugger and a compiler, and making those illegal is problematic. Very few people will have legitimate need for the physical equipment necessary, and even hardware developers won't need to be able to crack codes (such equipment could have a well-known (non-trusted) private/public key/signature for development purposes - possession of hardware with a different key, or where the key can be easily modified, will be presumptive of guilt).
The big flaw of the whole scheme is that when flaws are found, people's equipment will be disabled by having keys revoked, and if that happens enough the outcry will sink the whole thing.
With System 7 (and earlier), the last folder to have had both System and Finder (both of the correct file types, not just any file by those names) placed in it becomes "the" system folder. There were also some simple applications that would let you set which was the "blessed" system folder. This is similar to the way the default application was chosen - if you had multiple applications with the same creator, the last one to be moved into a folder (or renamed) was the default, so just move it to the another folder, then back.
With OS9, they made Startup Disk a lot smarter, and it would show you all of the folders with a system in it, and let you choose (which it did by using the same "blessed folder" mechanism). Startup Disk also has to set the preferences for which disk to boot from, and set the partition map to set which partition on that disk to boot - and details are different depending on if you're "old world" or "new world" boot ROM. Even with OSX, which doesn't allow multiple systems on one partition (because the boot partition becomes root, and too many things have fixed paths), there's still a blessed folder - normally/System/Library/CoreServices with a configuration file containing an Open Firmware script (along with some icon information and a binary loader that the script loads and runs) in BootX, which then loads the mach kernel.
And option-cmd-o-f which goes into the Open Firmware console.
Also, the folder name isn't significant, it is a "blessed" folder setting (pointed to in the master directory of an HFS disk) with a file called System (which used to be able to be modified by changing sector 0 of the disk or partition, back when sector 0 was actually a bootstrap sector with 68000 code in it - I don't know if the boot sequence still looks at the fields in that sector for the file names for System, Finder, Debugger, and a few other settings).
They don't need to, but they may have made an agreement with Intel to use EFI, for example. No one knows, other than a non-specific "Intel Macs don't use Open Firmware" line in a tech note, which could be referring to the new Macintels, or could just be commenting on the current developer-only leased machines.
Below a certain market penetration level, "most" vendors will be happy to ignore those customers. Any long-time Mac user can attest to that. For example, one of the only decent movie theaters near me only allows on-line ticket purchase/seat-reservation if you use IE. If you don't, either you can't even select your seat (one version of the javascript code), or when you go to purchase it they charge your card but don't issue you a ticket/reservation. Complaining about it simply gets "well, everyone can use IE, so why should we fix it? " Lots of banks only "support" IE on Windows for on-line banking - one had some strange javascript error where (in Safari), when you click on "pay my balance", which clears the "pay this amount" field, and then when you submit, complains that the field is empty. I complained and they explained that they only support IE.
That wasn't a critical error (I could either copy the balance amount to the manual field, or as I discovered, if I entered 0.01 in there AFTER I selected the "pay my balance", it ignored the amount and paid the balance anyway, and bypassed the javascript bug - but then they "fixed" that, and I ended up scheduling a 0.01 payment which I had to cancel - and just recently, the underlying bug has been FIXED). But it does show that there's still plenty of stuff that you're locked out of if you don't fall in line with the majority crowd.
If it gets to the point where you have to be running a trusted OS on a trusted hardware platform before any ISP will allow you onto the Internet, I'm not sure what choice you'll have. Will there be enough people with enough resources to create an alternate network? Will the government try to regulate that one as well? Will freedom-of-speech and freedom-to-associate win out, or will despotism finally eliminate those entirely?
Slashdot Mirror
You don't quite have all the sources, then - you don't have the private key, without which you can not generate the signature, which is a part of the binary. The GPL requires that you be able to modify the sources and be able to produce the binaries. The original signature file is not "source", and they haven't included all of the source needed to produce it.
In the example you give of the signed .tgz file, I would argue that the signature is not a part of the binary - it is accompanying the binary, but is never referenced, thus there's no requirement to be able to reproduce it.
In the case of the TiVo loader, given that it requires the signature, and given that it is NOT distributed independently of the GPL binary, it is NOT a "mere aggregation". One could even argue that such use means that they should be distributing the sources to the boot loader as well.
By the way, look for a Y2.1K, when programs call March 1, 2100 "February 29", because they get the century rule wrong.
And a LOT of programs don't get that rule right. In fact, a lot of programs didn't get that rule right even though 2000 would have been correct if they simply used the every-four-year rule and no other. There are still programs running that don't even get it right every FOUR years, because it happens so infrequently that people just live with it screwing up. So now you expect that a to-be-specified-in-the-future date to add an extra hour to a day is going to be put into programs, and TESTED, and actually work correctly? When the only real way to test it is to flip the switch telling all programs the world over to do it? The very first time?
I didn't ask "how do we test it?", I asked "when do we test it?", when no one is going to start even coding for it for 495 years. Y2K only had to deal with a legacy of around 40 years of people ignoring what might happen in 2000.
Having a leap second every year or so is an excellent way to weed out stupid programs that can't handle it. Having something happen only once every 500 years is asking for a disaster every 500 years. Right after Y2K, lots of programmers just said "well, at least that's done with, now all I have to do is hardcode in 2000 instead of 1900, and I don't have to worry about it - after all, this program can't possibly still be running in 3000!
a) the leap-year rule only goes out a few terms; it's still inaccurate over the really long term; b) in less than that really long term, the difference of a second every year doesn't make a difference; c) the period of the Earth's orbit around the Sun is also changing slowly, so no formula is going to be exact anyway.
That's not a leap hour. With the switch to DST, the time stays the same, but the representation is dependent on the time zone, and the time zone changes. If you aren't paying attention to the time zone, there is a discontinuity in the flow of hours, either time jumping forward by one hour or jumping back by one hour. Jumping back by one hour can be particularly bad when date order is important. Thus, any program that cares about the current "local time" uses standard routines and doesn't do any timekeeping based on the "local time hour".
With a leap hour, the time doesn't change, and the timezone doesn't change. You simply get an extra hour at the end of the day. Time goes from 23:59 to 24:00 to 24:01 to 24:59 to 00:00 the next day. It is nothing at all like the shift between standard and DST. However, it is still the case that the "number of seconds since Jan 1 1970" doesn't change - the shift with a leap second or leap hour is still only with the local representation of time, except that it changes it for all time zones at the same time.
True, asking what the minute is going to be in exactly 315532800 seconds from now is uncertain. So what? Anything that cares is going to simply store 315532800, not "10 years". If you want to schedule something to occur on July 30, 2015 at 11:17PM CDT, then presumably you'd want it to occur taking into account leap seconds as of that time (and any changes to Daylight Savings Time, as well). Nothing hard about that.
That's what I said - it is based off of "Atomic Time", which does not have leap seconds added. It then includes a field with the total offset from Atomic Time to UCT, i.e. the cumulative number of leap seconds since whatever epoch it is using. A GPS unit will add that value in when displaying local time, but the uncorrected value is used for all calculations.
No, the formula for leap years is based on the period of the Earth's rotation around the sun not being 365 days long. Leap seconds are based on variations in the Earth's rotation around its axis such that the day is not exactly 86,400 seconds. Completely independent, solving completely different problems (in one, the seasons drift, in the other noon drifts).
But the hour WON'T "jump forward or backward an hour". You'll either have a 23-hour or 25-hour day, plus it will only happen once every 500 years or so. When are you going to test it? When are you going to start putting it into programs? And you thought that programmers storing only 2 digits for the year were stupid and shortsighted...
The whole thing is a crock. Software that hardcodes in conversions between days/hours/minutes/seconds, AND needs to be so accurate to the rest of the world that it has to account for leap seconds, must be rewritten to use a standard library routine. Internally, it should simply keep a seconds counter, and base all intervals off of that. There's no excuse for doing it wrong, and code that does do it wrong should be rewritten if it is critical.
More likely, 500 years from now we won't be using the rotation of the Earth as a time base, as a majority of people will be elsewhere.
Regardless, I think it's time that software that can't handle leap seconds be updated - piss poor programming isn't an excuse for glossing over an inconvenience of nature, especially when the proper programming is already easy to do. Leap seconds shouldn't affect an internal clock, so anything doing interval timing should be unaffected. The only thing that should really care about leap seconds is something that is breaking things down into days/hours/minutes/seconds - primarily, for display purposes - or something that actually needs leap seconds, such as astronomy calculations (in which case, eliminating leap seconds for that application would be pointless). For display purposes, why should it matter if you get "60" for the seconds field? Or, more to the point, virtually all such systems have such inaccurate clocks, they shouldn't need to care about leap seconds between times that the time is manually reset. If they're using a GPS receiver as a time base, why not just make a modified receiver that doesn't report leap seconds? If for some reason the displayed time has to be in synch with "real time", make the clock run marginally fast or slow on the day that one occurs, for those few critical systems that somehow have a problem with it? GPS already runs off of "atomic time", with the total number of seconds offset to get to UTC (i.e. total number of leap seconds). Some GPS units actually use that value to figure out what the correct date is (since the weeks field wraps), based on an approximation of the number of leap seconds/year to expect.
The future will think us just as stupid and short-sighted as the people who assumed their programs wouldn't still be around beyond 19xx. Sure, virtually all programs TODAY won't be running in 500 years (though i wouldn't bet on NONE), but people will continue writing programs that won't support a "leap hour" (and the standards bodies won't even get around defining how to handle a leap hour until 3 years before it is to go into effect), and then EVERYTHING will die, or need to be shut down for an hour, when it becomes necessary. Better to have a leap second that occurs every year or two so that people don't get too complacent. There are systems that need to be shut down for the switch to/from DST, and systems that don't properly do leap year, or Feb 29. Why don't we eliminate leap years and DST so that those systems don't break?
Another alternative, just redefine the standard time zones to drift by a minute or so every ten years. Since the timezone file will need to be updated annually to accommodate idiots changing when DST is in effect anyway, it won't be much of a burden...
I thought they were changing the rating of the CURRENT version to AO, sending out stickers to retailers who want to continue selling stock-in-hand, and releasing the modified M-rated version.
I've always thought that the best way to actually eliminate something is to make it legal to be a consumer, illegal to be a provider (or the other way around). Thus, make using drugs legal, but selling or producing drugs remains illegal. I guess Microsoft finally figure out the same thing.
Someone should just add SMTP/IMAP as a protocol in Gaim (or build a proxy that does it).
And, of course, you can still experience PLATO today at http://cyber1.org/, TERM-talk, pnotes, notesfiles, avatar and empire and, well, not everything, but lots of it!
iChat sends each keystroke when using Rendezvous (which only works with locally connected clients).
Old news. We were doing that in the mid-70's.
e-mail almost always takes less than a couple seconds to be delivered across the Internet, and is practically instantaneous when sent to a local server. The problem is client programs not being notified, not that e-mail takes "too long", and part of that problem is POP. IMAP supports client notification, are there any IMAP servers which do that? Do any IMAP clients enable it?
I don't have a cell phone, but I can see that sending a text message would be much lower "attention overhead" than a phone call. With the phone call, you have to let it ring, wait for them to answer, ask you question, wait for them to answer, and go through a handshaking protocol ("hi, I just wanted to ask you a quick question"; "thanks, I'll talk to you later, bye"), and the other person has to be interrupted and wait for your question, then immediately take the time to find the answer and communicate it (or endure more overhead by having to call back later).
Actually, it is only poor implementations of e-mail that make it less immediate than IM (multi-user "chat" is different). Back in the '70s/'80s, on PLATO, we used TERM-talk (one-on-one typing to each other, even more immediate than IM - see "talk" on Unix systems - each person gets a line and what you type shows up immediately). We also had "e-mail", "newsgroups" and "chatrooms". We used Personal Notes (e-mail) the way people use IM now, because TERM-talk was exclusive - you could only be talking to one person at a time. pnotes notified you immediately when you had a message, so people would carry on near-real-time conversations with one or two lines per note. If you were gone, it was available when you got back. This was often done while also reading notesfiles, you could switch between the two fairly quickly without losing your place.
It really puzzled me when people started complaining about e-mail being "too slow", and that's why they used instant messaging, until I realized most people were using a POP mail reader or equivalent that only checked once every 5 minutes, and I was used to PLATO pnotes and Unix mail with "biff y". IMAP has a method where the server can notify the client immediately when new mail has arrived, but most servers don't seem to implement it.
Given that, I can see why "youngsters" would prefer IM - they're using it for socializing, not for doing "important work". IM is sometimes used for "important work", but almost always just as a priority notification, not for significant information transfer.
Are there any source code control systems that do what the old CDC modify program did (from at least as long ago as the '70s), where each line is identified, and a mod identifies the line(s) to be changed or moved? If the line is moved, it retains its identity, if it is modified it gets a new identity?
Darcs and similar models looks similar to the way modify was used. You had "modsets", which identified the list of mods to be applied and the order to apply them. If you had conflicting mods, you would create additional mods to fix the problem (including a directive "yank" to remove an already applied mod). You could include other modsets. You'd have a main line, and modsets for alternate tracks, alternate environments, experimental versions, etc. The main line would have mods "applied" on a regular basis, at which point active modsets would be updated to take into account new changes where necessary.
Darcs looks like it does some of those modifications to mods automatically. I'll have to look into it.
Your public key has to be signed by a valid key belonging to "The Trusted Computing Authority" or whatever it will be. Barring major breakthroughs in quantum computing or other means of doing prime factorization, the only way to break that would be physical theft or espionage. You can be pretty sure that security for those keys, and the process where they generate the key signature and burn it into each individual chip, will be extremely high. After all, if someone manages to get one of those keys, all processors that are validated using it will become non-trusted when the key gets revoked.
Could you noodle the private key out of an individual processor? Possibly - power attacks, timing attacks, physical attacks are all possible, but it remains to be seen if they will be effective. There are countermeasures for all of those. You wouldn't be able to release a broken private key, though - it will be revoked as soon as it becomes known that multiple systems are using it.
It will probably be easier to crack an individual work (software or content) through physical means, but "trusted systems" will be hardened against that as well (all "protected" content must not be exposed except between "trusted components" that have been authenticated). Finding one component of the chain which has a flaw might be possible, and once you've done that, you might be able to interfere with the authentication process (add in a new "trusted signing key", for example). That still won't get you on the Internet. Part of the signature of a key will certainly include what type of hardware it is, so breaking a sound chip won't let you pretend to be a memory controller or CPU or RAM chip.
You'll have to be a big vendor to get your application signed as trusted - if someone manages to sneak an emulator Easter Egg into it, the application will be revoked and users will be forced to upgrade immediately. Good luck getting an emulator into the next version.
I agree that the whole process is going to be complex enough that flaws are inevitable, either in the software or in the hardware, and cracked content will become available - but it will up the effort required to crack something enormously, and up the stakes as well. Possession of any of the equipment or keys necessary will be illegal. Currently, all you need is a debugger and a compiler, and making those illegal is problematic. Very few people will have legitimate need for the physical equipment necessary, and even hardware developers won't need to be able to crack codes (such equipment could have a well-known (non-trusted) private/public key/signature for development purposes - possession of hardware with a different key, or where the key can be easily modified, will be presumptive of guilt).
The big flaw of the whole scheme is that when flaws are found, people's equipment will be disabled by having keys revoked, and if that happens enough the outcry will sink the whole thing.
With System 7 (and earlier), the last folder to have had both System and Finder (both of the correct file types, not just any file by those names) placed in it becomes "the" system folder. There were also some simple applications that would let you set which was the "blessed" system folder. This is similar to the way the default application was chosen - if you had multiple applications with the same creator, the last one to be moved into a folder (or renamed) was the default, so just move it to the another folder, then back.
With OS9, they made Startup Disk a lot smarter, and it would show you all of the folders with a system in it, and let you choose (which it did by using the same "blessed folder" mechanism). Startup Disk also has to set the preferences for which disk to boot from, and set the partition map to set which partition on that disk to boot - and details are different depending on if you're "old world" or "new world" boot ROM. Even with OSX, which doesn't allow multiple systems on one partition (because the boot partition becomes root, and too many things have fixed paths), there's still a blessed folder - normally /System/Library/CoreServices with a configuration file containing an Open Firmware script (along with some icon information and a binary loader that the script loads and runs) in BootX, which then loads the mach kernel.
And option-cmd-o-f which goes into the Open Firmware console.
Also, the folder name isn't significant, it is a "blessed" folder setting (pointed to in the master directory of an HFS disk) with a file called System (which used to be able to be modified by changing sector 0 of the disk or partition, back when sector 0 was actually a bootstrap sector with 68000 code in it - I don't know if the boot sequence still looks at the fields in that sector for the file names for System, Finder, Debugger, and a few other settings).
They don't need to, but they may have made an agreement with Intel to use EFI, for example. No one knows, other than a non-specific "Intel Macs don't use Open Firmware" line in a tech note, which could be referring to the new Macintels, or could just be commenting on the current developer-only leased machines.
Below a certain market penetration level, "most" vendors will be happy to ignore those customers. Any long-time Mac user can attest to that. For example, one of the only decent movie theaters near me only allows on-line ticket purchase/seat-reservation if you use IE. If you don't, either you can't even select your seat (one version of the javascript code), or when you go to purchase it they charge your card but don't issue you a ticket/reservation. Complaining about it simply gets "well, everyone can use IE, so why should we fix it? " Lots of banks only "support" IE on Windows for on-line banking - one had some strange javascript error where (in Safari), when you click on "pay my balance", which clears the "pay this amount" field, and then when you submit, complains that the field is empty. I complained and they explained that they only support IE.
That wasn't a critical error (I could either copy the balance amount to the manual field, or as I discovered, if I entered 0.01 in there AFTER I selected the "pay my balance", it ignored the amount and paid the balance anyway, and bypassed the javascript bug - but then they "fixed" that, and I ended up scheduling a 0.01 payment which I had to cancel - and just recently, the underlying bug has been FIXED). But it does show that there's still plenty of stuff that you're locked out of if you don't fall in line with the majority crowd.
If it gets to the point where you have to be running a trusted OS on a trusted hardware platform before any ISP will allow you onto the Internet, I'm not sure what choice you'll have. Will there be enough people with enough resources to create an alternate network? Will the government try to regulate that one as well? Will freedom-of-speech and freedom-to-associate win out, or will despotism finally eliminate those entirely?