These use the "-i" inline feature of Perl, so even if you don't have "sed -i" available, Perl should be up to the task.
There is an interesting thread at http://mjg59.dreamwidth.org/12368.html.
Fedora 18's Grub bootloader and Linux kernel will be signed by Microsoft, so that hardware built for Windows 8, using the UEFI Secure Boot protocol, will also allow Fedora 18 to boot, signed by the Microsoft keys.
It appears that only Microsoft can sign UEFI Secure Boot keys. I may be wrong on this; if I am, then we get into the whole chain-of-trust issues that go with SSL (https) certificates. If it is only Microsoft (which seems to be the case), we would seem to be back into a monopoly position on x86 hardware. (Windows 8 on ARM doesn't require this, as Microsoft have a much weaker position on ARM hardware).
Matthew Garrett, a usually fearless and strongly outspoken RedHat / Fedora developer, has posted the article above, which has drawn a lot of comments.
What particularly comes out to me, is the question:
2012-05-31 09:18 am (UTC): What about debugging and tracing tools that use kernel modules like systemtap? Where does the user get the right signing key from to insert the instrumentation into the kernel?
and Matthew's reply:
2012-05-31 11:41 am (UTC): The user doesn't. If you want to be able to use technologies like that you'll have to disable secure boot on the system first.
Which says to me that Fedora (and RedHat, by implication) has lost one of its major features; if SystemTap is unavailable, then surely truss/strace is next. The Solaris 10/11 tool Dtrace stands no chance of being accepted.
What all of this seems to mean, is that Microsoft require the right to inspect the entire chain, from bootloader to kernel, to kernel modules, in order to allow that bootloader to start in the first place.
Some (not insignificant number) of RedHat customers use third-party kernel modules on their RedHat systems - Symantec's VxVM and VCS spring to mind. If RedHat can't guarantee that those modules won't be loaded, how can they get their kernel accepted by Microsoft?
So long as hardware comes with the ability to disable this Secure Boot feature, there is no real problem (other than for less technically savvy users who may not be accustomed to fiddling with BIOS settings).
When Microsoft's main commercial OS rival on enterprise x86 hardware buckles down and accepts Microsoft certifying all of their code (on an ongoing basis), that does not enhance the probability of such features being disabled by end-users in future.