Oh yeah? Restricting the boot environment is fundamental to all of that. This is a step towards the following scenario:
The bootloader must be signed, and the contract to get a signing key prevents the key holder from allowing anyone to install software that can be used to subvert the security model of any other installed software.
Installed software may be signed, and signed software can request that the OS prevent a debugger from attaching to the process.
The OS will provide a DRM service, essentially implementing a TPM in software if one is not present in hardware. The keys will be stored in an area of memory that not user process can read or write.
This is just an early step toward this, to soften us up and get us used to the idea of a restricted boot environment. It also allows Microsoft et al. to see what sort of unexpected problems might occur.
Really? Here are some references about boot malware which UEFI secure boot can prevent.
I am not denying that such things exist, but there is no reason for the standard to not require a method to install user generated certificates. It does not have to be easy to do, since it would not have to be done frequently: I could generate my own signing key, then sign as many custom bootloaders as a want to. That is the point of "custom mode," but there is a key problem here: there is no guarantee that custom mode will be available, and there is a mandate for ARM devices that run Windows that custom mode be unavailable.
These sorts of design decisions speak volumes about the purpose and scope of the standard. If the purpose of this standard were to protect users from malware, it would not make room for OEMs to lock users out of their own systems (i.e. right now an OEM has to specifically allow users to enable custom mode, as opposed to having to work to prevent users from doing so). Yes, this will make it much harder to create a bootloader virus, but I would view that as a side effect of the real security goal.
Let's put it this way: the restrictions on the PS3 prevent malware, but nobody would claim that is anything other than a side effect of the DRM-oriented design. We are looking at the same situation here: the security model treats a computer's user as the threat, and seeks to protect the DRM system from attacks by that threat. Bootloader malware (and probably other malware) will be prevented as a side effect, because such things are unapproved; the purpose of the approval process is to enable better DRM.
Right now, we are just seeing the first step. Microsoft and all the OEMs know that the shock of turning PCs into iPads will be too great and that users would flee; they are taking things slow, so that people have time to adjust to losing control over their computers before the change is finalized.
Adding your own keys is jumping through hoops? Why should hundreds of millions of people's security be put at risk because you are lazy to move one slider while moving between multiple distros?
Hundreds of millions of people's security is at risk? Bootloader malware is not even close to reaching that level of penetration. You could thwart bootloader malware almost as effectively by simply requiring that any writes to the MBR occur within some well-defined interactive session e.g. by creating a standardized way of installing an operating system, which cannot occur while another OS is already running (almost as effectively because yes, some users will be tricked into going through that process -- but burning a disk or writing to a thumb drive and then rebooting is enough work to prevent a typical social engineering attack).
This is and has always been about DRM. Bootloader malware is a secondary issue, almost a red herring. Yes, the process of installing keys and moving sliders around is another hoop to jump through in a procedure that already has too many hoops. Yes, there are better ways. No, I should not have to install every project's signing key when I want to install their distro. No, Fedora's tools are not enough, unless those tools allow me to sign a bootloader offline i.e. unless those tools basically give me Fedora's UEFI signing key.
Except that Canonical is in a position to demand that EFI boot restrictions be disabled by default. That does not seem to have entered the picture, because they do not care about user freedom. I disagree equally with Fedora's approach, because I personally switched away from Fedora when I disagreed with some changes they made, and this boot restriction system will make that harder to do.
Now is the time to fight back, not compromise. Bootloader restrictions are a direct attack on free software and user freedom, and the response by Canonical and the Fedora project has been to just lie down and accept that attack.
Part of the vision is that you should buy a Ubuntu system, right? In this case, Canonical is working with the OEMs to produce a certified system.
The vision is that you can buy a system that does not impose restrictions on what software you can run. The point of the GPLv3 is to advance that goal. Having Ubuntu but being unable to run a custom bootloader is not part of the vision.
This is "Better to avoid the problem altogether"
There is another option: require that any bootloader restrictions be disabled by default. If a user wants the restrictions to be enabled, nothing should stop them; but if the restrictions are enabled by default, an OEM may very well ship a system that does stop users from disabling those restrictions (otherwise, what's the point?).
Go complain to Microsoft if they try to make dual booting hard on such systems.
So you want what you what you not only do not have now, but somehow manage without.
The point is that we do have a real problem with GNU/Linux: switching distros is difficult and requires a lot of work, and sometimes you do not get what you wanted at the end. That is a problem that we should be working to solve or at least mitigate. This nonsense with signed bootloaders on personal computers is a step in the complete opposite direction.
That's the point of GPLv3: if these OEMs want to screw things up, then they have to deal with not getting to run GPLv3 software. If Canonical wants to make these "certified" hardware systems, then they should do one of the following:
Require that all certified systems ship with custom mode enabled by default, or that they ship without any restricted boot environment
Produce a separate key for every OEM, so that if one OEM screws up, they lose their Ubuntu certification without affecting other OEMs.
Otherwise, they are just legitimizing an attack on user freedoms, despite being the maintainers of the most popular GNU/Linux distribution out there (and despite the fact that those very freedoms are what enabled their entire operation).
Secure from what? The goal is not to secure you from a bootloader virus; I doubt that was discussed for more than five minutes while this system was being designed. The goal is to secure DRM systems from you, the user, because of what happened with DVDs and deCSS, what happens with software cracking tools, etc. The goal is to turn PCs into iPads.
This is a trap, designed to rob you of the freedom you have right now, which as it so happens is the freedom that PCs were meant to provide in the first place.
The expect that an OEM may screw up. In that case, their current solution will still allow users to run their own code except for the bootloader itself.
In other words, what we had with OtherOS on the PS3.
But if they used a GPLv3 bootloader, they have received advice that they might have to reveal the key when the OEM screws up, because that would be necessary for someone to provide their own bootloader.
How is that a bad thing? This is not a key that is used to protect military secrets, it's a key that serves exactly one purpose: to prevent people from running modified software.
Far better to not chance it and just avoid the GPLv3 for something that actually has a free license, rather than the significant impositions that GPLv3 attempts to impose in the name of the FSF's particular vision of "freedom".
Your freedom to throw punches ends where my face begins. My freedom to install software on my computer is not less important than some OEM's freedom to restrict what software runs on their products.
I don't understand why Microsoft requires secure boot. Care to explain?
Here is but one example: the market for video games is billions of dollars, and while a lot of that money is in consoles and phones, there is still plenty in PC games. The problem is that on my PC, I can modify the game in arbitrary ways -- I can remove a license check, I can cheat (BIG problem in MMOs), etc. The reason I can do this is that the OS has no good way to stop me -- even if Windows tried to prevent me from running unsigned code, I can run a program before Windows even boots up to get around that restriction.
Thus restricted boot environments become a necessity for Microsoft to turn Windows into a DRM-friendly platform. DRM on PCs is not dead, it was just on vacation while the big players worked on a way to sneak in restricted boot environments. No more grabbing secret keys out of running processes, no more replacing WoW DLLs to cheat, no more patching software to evade license checks. That's why Microsoft requires this.
That is also why we need to fight back against this.
While FSF just tries to fight their ideological war, Ubuntu takes less hard road and understands why Microsoft needs to employ secure boot. Good for them, and better for Linux.
How is this good for users? Restricted boot environments are about DRM, not about securing the system from malware. Canonical does not care about whether or not people can use the computers they own in the manner they wish to use them, so how is that a good thing?
I do not want to choose between Fedora and Ubuntu; I want to use whatever distro I fancy, and I want to be able to switch distros without jumping through hoops (yes, there are hoops to jump through now; this move by Canonical does nothing to advance any solution to that problem).
Well, you were close enough to win the cigar. The unfortunate history of today's tech giants is that they spent less time innovating and more time conquering the market. I suppose one might argue that there has been lots of innovation in business strategies, although I do not think that is what the Forbes article had in mind...
Has anyone claimed that GNU/Linux is innovative? It follows the design of Unix, which was a decision made when the project was started. There have been a few innovative extensions in GNU, but nothing too spectacular -- so what?
Shall we all run Unix, last of the True Innovative Operating Systems?
Really, you think Unix was the last innovative OS? There has been plenty of innovation in operating systems over the past 40 years, it just did not come from Microsoft or Apple.
Windows NT introduced pre-emptive multi-tasking to the Windows line which was then brought to the masses in Windows 95. Apple did not have pre-emptive multi-tasking on the desktop until it was introduced with OS X.
That is not innovative, that is catching up to innovations that occurred decades beforehand. As it so happens, Microsoft did sell a preemptive multitasking OS for PCs before Windows NT:
Atoms aren't patentable. We know that machines are just a collection of atoms. Therefore, no machine should be patentable.
Except that a collection of atoms is not an atom in and of itself. When you combine mathematical results, you have yet another mathematical result.
There are several good arguments for why software patents do not achieve the goals that the patent system is supposed to have. "Software is just math" is not one of them.
Actually, it is a common criticism of software patents. Both the Church-Turing thesis and the Curry-Howard correspondence have been pointed to in debates about software patents, especially in cases where the patents cover nothing more than common algebraic, number theoretic, or statistical techniques where the variables have been given specific labels (i.e. the patent is on how you interpret a set of variables). See, for example, the criticism of the eHarmony patent:
In general, when there is such an obvious patent on math, it is criticized for being a patent on math. Yet anyone with an undergrad level education in the theory of computation knows that all software is math; it is just less obvious in most cases because of the abstractions we use, which are designed to make us think that we are building a machine of some sort.
So why make apologies for software patents? Either we stop trying to uphold the previous principles that made math unpatentable, or we stop giving out patents on math that is expressed as software. Otherwise we just have the mess that we see today.
Apple DOS was not innovative, Mac OS 1,2,3,4,5,6,7,8,9, OS X wasn't innovative.
OK, I do not dispute that. I never claimed that Apple is an innovative company. In general, Apple grabs innovative technologies, wraps them up in a pretty package, and monetizes them.
Innovation is sometime an incremental improvement, then a big Gee-Wiz everything is brand new.
Which of these has Microsoft done? How did the DOS, Windows, Windows NT, Office, or any other Microsoft product line improve the state of the art?
Innovator in what, exactly? DOS was not innovative, Windows 1, 2, 3, 3.1, NT 3.5, NT4 were not innovative, Office was not innovative, etc. So what innovations are you referring to?
My compiler is pretty much doing it for me, and that its way of doing it; typeid is an operator
OK, so my C compiler pretty much does OOP constructs for me, because I can use structs and pointers.
It's done this way because fortunately C++ is a static language and requires compile-time resolution
Except, of course, for method dispatch. Multiple dispatch does not require a dynamic language, but it does require a more complicated dispatch system than what you see in C++. You can emulate double dispatching using a visitor pattern, and you can extend that to emulate multiple dispatch in general if you are willing to put in the effort. You can also implement your own version of a vtbl that supports multiple dispatch, but with the trade-off of losing static analysis (or having to jump through hoops to get it).
Regarding introspection, you can already do it with templates
Which is ugly and results in horribly complicated code.
Restarts are something that I strongly oppose because they only address the representation of your program in memory
Restarts also give you a clean way to deal with correctable errors, and more general continuations (e.g. call/cc in Scheme) provide clean solutions to a variety of programming issues.
and your objects can represent a lot more than that.
Except that relying on objects for everything results in vastly more complicated designs. Even when you are making proper use of OO design patterns, you will still wind up with more complicated designs for things like restarts, continuations, and multiple dispatch. C++11 introduced lambda expressions and lexical closures because of that problem -- it was very annoying to have to specify an entirely new class in situations where you only needed a closure, and it made code more complicated than it needed to be.
Who cares?
I thought this was a conversation about C++ and the C++ standard. If it is not, then why are we even bothering? You can get a garbage collection library for C++, you can get a library that allows you to create restarts, you can get a separate tool that adds AOP constructs, etc. You can just get a C++ implementation of Scheme, and suddenly all of Scheme's features are available in your program (or even better, you can use Guile and write some code in C++, and other code in Scheme)!
This is not much different from the old Lisp practice of creating things like Prolog-in-Lisp. Sure, you can get libraries for these things, but if Prolog-in-Lisp does not make Lisp a logic language, then how can a C++ library turn C++ into something it is not?
Performance matters.
Sometimes that is true, but so what? High level languages do not necessarily perform poorly, and with today's compiler technologies the performance is generally comparable to C++ (unless you are talking about C++ programs that are loaded with hacks and tricks to squeeze the last bit of performance out; sure, I can grant that, but in most cases that is not what you see and when you do see it it is usually not portable). JIT optimizers can often do things at runtime that C++ compilers cannot do.
There are also plenty of cases where reliability is more important than performance. Do you care more about the extra few seconds that you spend waiting at the ATM or about the ATM dispensing the correct amount of money?
They are not necessary, but the advantage of native code is that it is very easy to debug and there are plenty of tools to do it.
Debugging C++ programs is not easy in any sense of the term, and native code in general is not easier to debug than managed or machine independent code.
You should not be catching exceptions to correct errors.
I never said that the language didn't have safety issues, what I said was that the language was missing features, not safety, as in I don't need it to be safer, I just want more features.
OK, good for you -- but we live in a world where the unsafe nature of C++ has created a brittle, vulnerable, unreliable software ecosystem. It is easy to be a snob and declare that the problem is that programmers are just too inexperienced to really make use of C++, but if that is the reality of the world, then the problem is C++, not the programmers.
That's not an error resulting from attempting to free the resource
Yes it is -- closing a file is, by your own admission, freeing a resource, and attempts to close a file might cause an I/O error.
If you want to be clean (and slow) you can always fsync() first to separate the synchronization from the deallocation
Except that the destructor might be called as part of a stack unwinding, in which case you will not get the chance to do that. Yes, I know, in your world if the destructor has an error that it cannot recover from on its own, the error should either be ignored or the program should crash.
All exceptions relating to freeing resources should be let through, because if a destructor can't deallocate, then the program has crashed; all other exceptions must be suppressed
In other words, allow potentially correctable errors to go unhandled, which is known as "failing silently."
Can you please give me an example of an error worthy of an exception that can be corrected without human interaction?
What do you think should be done when an error that is "unworthy" of an exception occurs? What determines whether or not an error is "worthy" of an exception?
What difference does it make if human interaction is required? Most errors cannot be automatically corrected; many errors can be corrected by the user. It is almost never correct to allow errors to occur with no handling at all.
You left out the part where it might be OK to ignore the error e.g. if an error occurs while logging you might want to complete higher priority tasks, or if a line of input is malformed the user might want to just skip it and read the rest of the input, or it might be acceptable for some operation to be partially completed, etc. Only the client of the class should be responsible for that sort of decision.
Following that also provide an explanation as to why the caller would be better suited to correct the error than the callee when the caller isn't supposed to know anything about the callee's internals
The caller does not need to know anything about the internals; the caller only needs to know that a particular kind of exception was thrown, and that the exception should be handled in some particular way. You streams classes don't know whether or not it is OK to ignore I/O errors, nor should they know, which is why an exception is thrown: the client of the class is better able to decide what to do about the error. A class for managing records should not know whether or not the user should be prompted to correct an error or skip over an error or if the program needs to run without user interaction, nor should the class know whether that prompt should be a GUI dialog, a beeping sound on a device with a button, or just a message to stdout followed by a read from stdin.
Sure, you can do this without restarts, but it will result in a fantastically complicated design that will essentially implement a system of restarts, or an equally complicated design that will allow you to rollback operations and try them again. Or you can just punt on this, declare that errors that could be corrected but where the decision can only be made by clients of your class are not really correctable errors, and create software that is less reliable and that angers its users. How are any of these better options?
From a design point of view, it makes no sense because your caller isn't expecting it; from a quality point of view, it makes your class a little more reliable.
In another post, you claimed that C++ is only missing features, and there is no safety issue. Are you changing you mind about that one? The C++ standard requires a basic_filebuf to perform a sync in its destructor, and to allow that sync to silently fail.
I never said that a destructor should fail silently, I said that exceptions unrelated to deallocation should be caught by the destructor because those do not compromise the destructor's purpose, which is to deallocate everything.
OK, but what about errors that are the result of an attempt to free resources, like an I/O error that results from closing a file?
There only responsibility that a destructor has is to free resources.
Are we going to loop on this? Sometimes errors occur while resources are being freed. If an exception cannot leave a destructor, then the destructor is responsible for both freeing resources and for dealing with errors, or else you just abort whenever you have an error while freeing resources.
And exactly does that solve your problem any better than creating a new stream and retrying the operation on it?
As an example, the exception might have been thrown in the middle of writing record-oriented data (i.e. the logging facility threw an exception before the record was completely written); if you are unable to resume the operation, then you will either need to have a way to roll back the partially completed write (which may be ugly, e.g. if your stream was a socket), or a way to keep track of how much you had written (or the third option: you wind up with a corrupt file). Restarts provide a much cleaner solution here: if the error can be corrected or if it is safe to ignore, you can safely continue with the operation, without having to waste time on rolling things back and without having to keep redundant information about how much had been written (which is already tracked by the stream, except that the stream has no knowledge of your record structure). You also allow the clients of your class to decide priorities without having to know the details of your implementation: maybe logging is not important and can be skipped, or maybe logging is of equal importance to writing the records.
Can you name a valid RTTI use that you don't consider a "hack"? Can you explain the existence of RTTI if not to solve this particular issue? And if you agree that RTTI exists to solve this particular issue, then what makes my intended use of it a "hack"?
Well, it may just be a matter of opinion at this point, but if you are using RTTI to do something that your compiler could have done for you, then I would say you are writing a hack. This is not always the case, of course; dynamic_cast should be used if you are performing a cast down an inheritance hierarchy, but cannot guarantee that the cast will be valid (i.e. the client might use your code the wrong way, in which case an exception should be thrown). That is not the case here; here, you are using RTTI to implement a missing language feature (multiple dispatch); you might not call it a hack, but I would, just like I would call implementing objects in C by using structs and function pointers a hack.
What can you not do with the library that you think is necessary and should absolutely be in the core?
Well until C++11, lambda expressions -- yes, there was the Boost lambda expressions library, but that was not quite what was needed and it was not part of the standard. It would also be nice to have a built-in multiple dispatch facility (see above; the language only provides bits and pieces that can be used to implement multiple dispatch by hand), a more complete introspection system (not something I frequently use, but some people do), restarts or continuations (beyond what you can hack together with setjmp and longjmp), etc. The C++ language is missing quite a few modern features that other languages provide.
I hope, for the sake of competence, that you are aware that all those examples you give can be fixed by proper debug libraries with custom smart pointers, custom array containers, custom allocators, and custom new, new[], delete, and delete[] overloads.
Which is just a way of saying, "The standard is missing the things you need in those cases." If you are using the word "custom," then you are no longer talking about what the language itself provides.
Also, thanks to being a native language, C++ can take advantage of all the available native debugging tools
Which are not standardized across operating systems, hardware architectures, etc. If these things are necessary for C++ programmers to do their work effectively, then they should be part of the standard.
Lastly, these are problems that you continue to have to deal in higher level languages, except you may not end up having security issues because of them,
Even if that statement were true, it would be a huge improvement to move to higher level languages.
Not without violating the principle of self-containment. So far in this thread everyone claiming that C++ exceptions have a problem are yet to demonstrate a single case in which catching a destructor exception would make any sense and does not imply bad design of their classes, so feel free to try...
See my other post about restarts; basically, when an exception is thrown, it should be possible for the thrower to set restart points that the exception handler can jump to once the error is corrected (or perhaps if the error can safely be ignored, etc.).
Because you might have cases in which functions called in the context of destruction (i.e.: functions called to free resources) may signal error conditions related to freeing resources, and in these cases the exception should be allowed to propagate so that the program can abort, because if your destructor, which is supposed to be in the best position to do the job, can not destroy parts of the object that it represents or ensure that the destruction doesn't leave side effects behind, then the program is in no condition to con
Slashdot Mirror
This is just an early step toward this, to soften us up and get us used to the idea of a restricted boot environment. It also allows Microsoft et al. to see what sort of unexpected problems might occur.
Really? Here are some references about boot malware which UEFI secure boot can prevent.
I am not denying that such things exist, but there is no reason for the standard to not require a method to install user generated certificates. It does not have to be easy to do, since it would not have to be done frequently: I could generate my own signing key, then sign as many custom bootloaders as a want to. That is the point of "custom mode," but there is a key problem here: there is no guarantee that custom mode will be available, and there is a mandate for ARM devices that run Windows that custom mode be unavailable.
These sorts of design decisions speak volumes about the purpose and scope of the standard. If the purpose of this standard were to protect users from malware, it would not make room for OEMs to lock users out of their own systems (i.e. right now an OEM has to specifically allow users to enable custom mode, as opposed to having to work to prevent users from doing so). Yes, this will make it much harder to create a bootloader virus, but I would view that as a side effect of the real security goal.
Let's put it this way: the restrictions on the PS3 prevent malware, but nobody would claim that is anything other than a side effect of the DRM-oriented design. We are looking at the same situation here: the security model treats a computer's user as the threat, and seeks to protect the DRM system from attacks by that threat. Bootloader malware (and probably other malware) will be prevented as a side effect, because such things are unapproved; the purpose of the approval process is to enable better DRM.
Right now, we are just seeing the first step. Microsoft and all the OEMs know that the shock of turning PCs into iPads will be too great and that users would flee; they are taking things slow, so that people have time to adjust to losing control over their computers before the change is finalized.
Adding your own keys is jumping through hoops? Why should hundreds of millions of people's security be put at risk because you are lazy to move one slider while moving between multiple distros?
Hundreds of millions of people's security is at risk? Bootloader malware is not even close to reaching that level of penetration. You could thwart bootloader malware almost as effectively by simply requiring that any writes to the MBR occur within some well-defined interactive session e.g. by creating a standardized way of installing an operating system, which cannot occur while another OS is already running (almost as effectively because yes, some users will be tricked into going through that process -- but burning a disk or writing to a thumb drive and then rebooting is enough work to prevent a typical social engineering attack).
This is and has always been about DRM. Bootloader malware is a secondary issue, almost a red herring. Yes, the process of installing keys and moving sliders around is another hoop to jump through in a procedure that already has too many hoops. Yes, there are better ways. No, I should not have to install every project's signing key when I want to install their distro. No, Fedora's tools are not enough, unless those tools allow me to sign a bootloader offline i.e. unless those tools basically give me Fedora's UEFI signing key.
Since you can install your own certificates on your local machine
There is no guarantee of that; see, for example, the iPad.
Except that Canonical is in a position to demand that EFI boot restrictions be disabled by default. That does not seem to have entered the picture, because they do not care about user freedom. I disagree equally with Fedora's approach, because I personally switched away from Fedora when I disagreed with some changes they made, and this boot restriction system will make that harder to do.
Now is the time to fight back, not compromise. Bootloader restrictions are a direct attack on free software and user freedom, and the response by Canonical and the Fedora project has been to just lie down and accept that attack.
Part of the vision is that you should buy a Ubuntu system, right? In this case, Canonical is working with the OEMs to produce a certified system.
The vision is that you can buy a system that does not impose restrictions on what software you can run. The point of the GPLv3 is to advance that goal. Having Ubuntu but being unable to run a custom bootloader is not part of the vision.
This is "Better to avoid the problem altogether"
There is another option: require that any bootloader restrictions be disabled by default. If a user wants the restrictions to be enabled, nothing should stop them; but if the restrictions are enabled by default, an OEM may very well ship a system that does stop users from disabling those restrictions (otherwise, what's the point?).
Go complain to Microsoft if they try to make dual booting hard on such systems.
So you want what you what you not only do not have now, but somehow manage without.
The point is that we do have a real problem with GNU/Linux: switching distros is difficult and requires a lot of work, and sometimes you do not get what you wanted at the end. That is a problem that we should be working to solve or at least mitigate. This nonsense with signed bootloaders on personal computers is a step in the complete opposite direction.
Otherwise, they are just legitimizing an attack on user freedoms, despite being the maintainers of the most popular GNU/Linux distribution out there (and despite the fact that those very freedoms are what enabled their entire operation).
Just ask Sony or MS how well that turned out
Keep in mind that it took four years to break the PS3 DRM, and even now the majority of PS3 owners are not in a position to jailbreak their devices.
If the only thing keeping this secure
Secure from what? The goal is not to secure you from a bootloader virus; I doubt that was discussed for more than five minutes while this system was being designed. The goal is to secure DRM systems from you, the user, because of what happened with DVDs and deCSS, what happens with software cracking tools, etc. The goal is to turn PCs into iPads.
This is a trap, designed to rob you of the freedom you have right now, which as it so happens is the freedom that PCs were meant to provide in the first place.
The expect that an OEM may screw up. In that case, their current solution will still allow users to run their own code except for the bootloader itself.
In other words, what we had with OtherOS on the PS3.
But if they used a GPLv3 bootloader, they have received advice that they might have to reveal the key when the OEM screws up, because that would be necessary for someone to provide their own bootloader.
How is that a bad thing? This is not a key that is used to protect military secrets, it's a key that serves exactly one purpose: to prevent people from running modified software.
Far better to not chance it and just avoid the GPLv3 for something that actually has a free license, rather than the significant impositions that GPLv3 attempts to impose in the name of the FSF's particular vision of "freedom".
Your freedom to throw punches ends where my face begins. My freedom to install software on my computer is not less important than some OEM's freedom to restrict what software runs on their products.
I mean reasons that benefit the user
That never enters the picture; users, in this model, are nothing more than an exploitable resource, a source of revenue for the corporate overlords.
I don't understand why Microsoft requires secure boot. Care to explain?
Here is but one example: the market for video games is billions of dollars, and while a lot of that money is in consoles and phones, there is still plenty in PC games. The problem is that on my PC, I can modify the game in arbitrary ways -- I can remove a license check, I can cheat (BIG problem in MMOs), etc. The reason I can do this is that the OS has no good way to stop me -- even if Windows tried to prevent me from running unsigned code, I can run a program before Windows even boots up to get around that restriction.
Thus restricted boot environments become a necessity for Microsoft to turn Windows into a DRM-friendly platform. DRM on PCs is not dead, it was just on vacation while the big players worked on a way to sneak in restricted boot environments. No more grabbing secret keys out of running processes, no more replacing WoW DLLs to cheat, no more patching software to evade license checks. That's why Microsoft requires this.
That is also why we need to fight back against this.
While FSF just tries to fight their ideological war, Ubuntu takes less hard road and understands why Microsoft needs to employ secure boot. Good for them, and better for Linux.
How is this good for users? Restricted boot environments are about DRM, not about securing the system from malware. Canonical does not care about whether or not people can use the computers they own in the manner they wish to use them, so how is that a good thing?
I do not want to choose between Fedora and Ubuntu; I want to use whatever distro I fancy, and I want to be able to switch distros without jumping through hoops (yes, there are hoops to jump through now; this move by Canonical does nothing to advance any solution to that problem).
They innovated the idea of selling the OS separate from the hardware
No they didn't:
https://en.wikipedia.org/wiki/Unix
They innovated using a graphical WYSISWG interface for office programs... no wait apple did that.
Actually, that one was Xerox:
https://en.wikipedia.org/wiki/Bravo_(software)
Oh well, it was a good question and I tried.
Well, you were close enough to win the cigar. The unfortunate history of today's tech giants is that they spent less time innovating and more time conquering the market. I suppose one might argue that there has been lots of innovation in business strategies, although I do not think that is what the Forbes article had in mind...
What has Linux done?
Has anyone claimed that GNU/Linux is innovative? It follows the design of Unix, which was a decision made when the project was started. There have been a few innovative extensions in GNU, but nothing too spectacular -- so what?
Shall we all run Unix, last of the True Innovative Operating Systems?
Really, you think Unix was the last innovative OS? There has been plenty of innovation in operating systems over the past 40 years, it just did not come from Microsoft or Apple.
Windows NT introduced pre-emptive multi-tasking to the Windows line which was then brought to the masses in Windows 95. Apple did not have pre-emptive multi-tasking on the desktop until it was introduced with OS X.
That is not innovative, that is catching up to innovations that occurred decades beforehand. As it so happens, Microsoft did sell a preemptive multitasking OS for PCs before Windows NT:
https://en.wikipedia.org/wiki/Xenix
That was not innovative either, they simply licensed the system from AT&T.
Atoms aren't patentable. We know that machines are just a collection of atoms. Therefore, no machine should be patentable.
Except that a collection of atoms is not an atom in and of itself. When you combine mathematical results, you have yet another mathematical result.
There are several good arguments for why software patents do not achieve the goals that the patent system is supposed to have. "Software is just math" is not one of them.
Actually, it is a common criticism of software patents. Both the Church-Turing thesis and the Curry-Howard correspondence have been pointed to in debates about software patents, especially in cases where the patents cover nothing more than common algebraic, number theoretic, or statistical techniques where the variables have been given specific labels (i.e. the patent is on how you interpret a set of variables). See, for example, the criticism of the eHarmony patent:
http://www.technollama.co.uk/patenting-maths
In general, when there is such an obvious patent on math, it is criticized for being a patent on math. Yet anyone with an undergrad level education in the theory of computation knows that all software is math; it is just less obvious in most cases because of the abstractions we use, which are designed to make us think that we are building a machine of some sort.
I've seen some software things done that were truly patent-worthy
Except that mathematics is not patentable, and we has fundamental results about software being a form of math:
https://en.wikipedia.org/wiki/Curry-Howard_Isomorphism
So why make apologies for software patents? Either we stop trying to uphold the previous principles that made math unpatentable, or we stop giving out patents on math that is expressed as software. Otherwise we just have the mess that we see today.
Apple DOS was not innovative, Mac OS 1,2,3,4,5,6,7,8,9, OS X wasn't innovative.
OK, I do not dispute that. I never claimed that Apple is an innovative company. In general, Apple grabs innovative technologies, wraps them up in a pretty package, and monetizes them.
Innovation is sometime an incremental improvement, then a big Gee-Wiz everything is brand new.
Which of these has Microsoft done? How did the DOS, Windows, Windows NT, Office, or any other Microsoft product line improve the state of the art?
Innovator in what, exactly? DOS was not innovative, Windows 1, 2, 3, 3.1, NT 3.5, NT4 were not innovative, Office was not innovative, etc. So what innovations are you referring to?
Apple Research
My compiler is pretty much doing it for me, and that its way of doing it; typeid is an operator
OK, so my C compiler pretty much does OOP constructs for me, because I can use structs and pointers.
It's done this way because fortunately C++ is a static language and requires compile-time resolution
Except, of course, for method dispatch. Multiple dispatch does not require a dynamic language, but it does require a more complicated dispatch system than what you see in C++. You can emulate double dispatching using a visitor pattern, and you can extend that to emulate multiple dispatch in general if you are willing to put in the effort. You can also implement your own version of a vtbl that supports multiple dispatch, but with the trade-off of losing static analysis (or having to jump through hoops to get it).
Regarding introspection, you can already do it with templates
Which is ugly and results in horribly complicated code.
Restarts are something that I strongly oppose because they only address the representation of your program in memory
Restarts also give you a clean way to deal with correctable errors, and more general continuations (e.g. call/cc in Scheme) provide clean solutions to a variety of programming issues.
and your objects can represent a lot more than that.
Except that relying on objects for everything results in vastly more complicated designs. Even when you are making proper use of OO design patterns, you will still wind up with more complicated designs for things like restarts, continuations, and multiple dispatch. C++11 introduced lambda expressions and lexical closures because of that problem -- it was very annoying to have to specify an entirely new class in situations where you only needed a closure, and it made code more complicated than it needed to be.
Who cares?
I thought this was a conversation about C++ and the C++ standard. If it is not, then why are we even bothering? You can get a garbage collection library for C++, you can get a library that allows you to create restarts, you can get a separate tool that adds AOP constructs, etc. You can just get a C++ implementation of Scheme, and suddenly all of Scheme's features are available in your program (or even better, you can use Guile and write some code in C++, and other code in Scheme)!
This is not much different from the old Lisp practice of creating things like Prolog-in-Lisp. Sure, you can get libraries for these things, but if Prolog-in-Lisp does not make Lisp a logic language, then how can a C++ library turn C++ into something it is not?
Performance matters.
Sometimes that is true, but so what? High level languages do not necessarily perform poorly, and with today's compiler technologies the performance is generally comparable to C++ (unless you are talking about C++ programs that are loaded with hacks and tricks to squeeze the last bit of performance out; sure, I can grant that, but in most cases that is not what you see and when you do see it it is usually not portable). JIT optimizers can often do things at runtime that C++ compilers cannot do.
There are also plenty of cases where reliability is more important than performance. Do you care more about the extra few seconds that you spend waiting at the ATM or about the ATM dispensing the correct amount of money?
They are not necessary, but the advantage of native code is that it is very easy to debug and there are plenty of tools to do it.
Debugging C++ programs is not easy in any sense of the term, and native code in general is not easier to debug than managed or machine independent code.
You should not be catching exceptions to correct errors.
So your streams class should know whethe
I never said that the language didn't have safety issues, what I said was that the language was missing features, not safety, as in I don't need it to be safer, I just want more features.
OK, good for you -- but we live in a world where the unsafe nature of C++ has created a brittle, vulnerable, unreliable software ecosystem. It is easy to be a snob and declare that the problem is that programmers are just too inexperienced to really make use of C++, but if that is the reality of the world, then the problem is C++, not the programmers.
That's not an error resulting from attempting to free the resource
Yes it is -- closing a file is, by your own admission, freeing a resource, and attempts to close a file might cause an I/O error.
If you want to be clean (and slow) you can always fsync() first to separate the synchronization from the deallocation
Except that the destructor might be called as part of a stack unwinding, in which case you will not get the chance to do that. Yes, I know, in your world if the destructor has an error that it cannot recover from on its own, the error should either be ignored or the program should crash.
All exceptions relating to freeing resources should be let through, because if a destructor can't deallocate, then the program has crashed; all other exceptions must be suppressed
In other words, allow potentially correctable errors to go unhandled, which is known as "failing silently."
Can you please give me an example of an error worthy of an exception that can be corrected without human interaction?
Following that also provide an explanation as to why the caller would be better suited to correct the error than the callee when the caller isn't supposed to know anything about the callee's internals
The caller does not need to know anything about the internals; the caller only needs to know that a particular kind of exception was thrown, and that the exception should be handled in some particular way. You streams classes don't know whether or not it is OK to ignore I/O errors, nor should they know, which is why an exception is thrown: the client of the class is better able to decide what to do about the error. A class for managing records should not know whether or not the user should be prompted to correct an error or skip over an error or if the program needs to run without user interaction, nor should the class know whether that prompt should be a GUI dialog, a beeping sound on a device with a button, or just a message to stdout followed by a read from stdin.
Sure, you can do this without restarts, but it will result in a fantastically complicated design that will essentially implement a system of restarts, or an equally complicated design that will allow you to rollback operations and try them again. Or you can just punt on this, declare that errors that could be corrected but where the decision can only be made by clients of your class are not really correctable errors, and create software that is less reliable and that angers its users. How are any of these better options?
From a design point of view, it makes no sense because your caller isn't expecting it; from a quality point of view, it makes your class a little more reliable.
In another post, you claimed that C++ is only missing features, and there is no safety issue. Are you changing you mind about that one? The C++ standard requires a basic_filebuf to perform a sync in its destructor, and to allow that sync to silently fail.
I never said that a destructor should fail silently, I said that exceptions unrelated to deallocation should be caught by the destructor because those do not compromise the destructor's purpose, which is to deallocate everything.
OK, but what about errors that are the result of an attempt to free resources, like an I/O error that results from closing a file?
There only responsibility that a destructor has is to free resources.
Are we going to loop on this? Sometimes errors occur while resources are being freed. If an exception cannot leave a destructor, then the destructor is responsible for both freeing resources and for dealing with errors, or else you just abort whenever you have an error while freeing resources.
And exactly does that solve your problem any better than creating a new stream and retrying the operation on it?
As an example, the exception might have been thrown in the middle of writing record-oriented data (i.e. the logging facility threw an exception before the record was completely written); if you are unable to resume the operation, then you will either need to have a way to roll back the partially completed write (which may be ugly, e.g. if your stream was a socket), or a way to keep track of how much you had written (or the third option: you wind up with a corrupt file). Restarts provide a much cleaner solution here: if the error can be corrected or if it is safe to ignore, you can safely continue with the operation, without having to waste time on rolling things back and without having to keep redundant information about how much had been written (which is already tracked by the stream, except that the stream has no knowledge of your record structure). You also allow the clients of your class to decide priorities without having to know the details of your implementation: maybe logging is not important and can be skipped, or maybe logging is of equal importance to writing the records.
Can you name a valid RTTI use that you don't consider a "hack"? Can you explain the existence of RTTI if not to solve this particular issue? And if you agree that RTTI exists to solve this particular issue, then what makes my intended use of it a "hack"?
Well, it may just be a matter of opinion at this point, but if you are using RTTI to do something that your compiler could have done for you, then I would say you are writing a hack. This is not always the case, of course; dynamic_cast should be used if you are performing a cast down an inheritance hierarchy, but cannot guarantee that the cast will be valid (i.e. the client might use your code the wrong way, in which case an exception should be thrown). That is not the case here; here, you are using RTTI to implement a missing language feature (multiple dispatch); you might not call it a hack, but I would, just like I would call implementing objects in C by using structs and function pointers a hack.
What can you not do with the library that you think is necessary and should absolutely be in the core?
Well until C++11, lambda expressions -- yes, there was the Boost lambda expressions library, but that was not quite what was needed and it was not part of the standard. It would also be nice to have a built-in multiple dispatch facility (see above; the language only provides bits and pieces that can be used to implement multiple dispatch by hand), a more complete introspection system (not something I frequently use, but some people do), restarts or continuations (beyond what you can hack together with setjmp and longjmp), etc. The C++ language is missing quite a few modern features that other languages provide.
I hope, for the sake of competence, that you are aware that all those examples you give can be fixed by proper debug libraries with custom smart pointers, custom array containers, custom allocators, and custom new, new[], delete, and delete[] overloads.
Which is just a way of saying, "The standard is missing the things you need in those cases." If you are using the word "custom," then you are no longer talking about what the language itself provides.
Also, thanks to being a native language, C++ can take advantage of all the available native debugging tools
Which are not standardized across operating systems, hardware architectures, etc. If these things are necessary for C++ programmers to do their work effectively, then they should be part of the standard.
Lastly, these are problems that you continue to have to deal in higher level languages, except you may not end up having security issues because of them,
Even if that statement were true, it would be a huge improvement to move to higher level languages.
Not without violating the principle of self-containment. So far in this thread everyone claiming that C++ exceptions have a problem are yet to demonstrate a single case in which catching a destructor exception would make any sense and does not imply bad design of their classes, so feel free to try...
See my other post about restarts; basically, when an exception is thrown, it should be possible for the thrower to set restart points that the exception handler can jump to once the error is corrected (or perhaps if the error can safely be ignored, etc.).
Because you might have cases in which functions called in the context of destruction (i.e.: functions called to free resources) may signal error conditions related to freeing resources, and in these cases the exception should be allowed to propagate so that the program can abort, because if your destructor, which is supposed to be in the best position to do the job, can not destroy parts of the object that it represents or ensure that the destruction doesn't leave side effects behind, then the program is in no condition to con