The classical education of the Trivium is probably a much better fit for educating humans, as opposed to the factory farming methods of the 20th Century. It far better fits the developmental stages as they occur. I suspect as we move away from the need for uniform but low quality graduates, and try to get competitive intellectually in the world, the focus will naturally shift back to this superior form of education.
I received a 128 Gb Kingston SSDnow as a gift from a friend, to put in my laptop. The laptop had a 320 Gb hard drive, so I've had to not lug 2 years of photos around, but it's well worth it because this this is damned fast. Things that had 10 second times now are sub-second. The thing boots Windows 7 in less than 10 seconds.
Capacity is nice, but once you get past 40Gb or so, you only need it to store images and things in bulk. It's like having the speed of a SAN in a laptop. SSD is an order of magnitude faster as far as the user experience goes, and if you can get one for less than $200, it's well worth doing, IMHO.
Once the end users see this in action, the price/Gb won't matter to them, because responsiveness is the name of the game.
I'm not talking about the margins either... if HTML did what it said on the tin, you'd be able to highlight text someone else wrote, and more advanced versions would let you circle things, and photos, or whatever.
The ability to put a mark on top of something, to mark up 1 layer..
Paper allows markup, and so does papyrus. Clay tablets do as well, until they are dry or fired in a kiln.
Paperless "documents" can be made to support markup. Ted Nelson was talking about it in the 1960s. It's his inability to ship product (like Babbage before him) that kept his vision from being popularized.
When TBL got around to building the first web servers, and there arose a need for formatting, the term HTML got picked. The world was done a great disservice by the term HTML, which doesn't allow markup of text, let alone hypertext.
HTML has effectively banned discussion of old school markup, because for a large portion of cases, people didn't really need markup, they just wanted formatting, so they went along with the term. Anyone who wanted old school markup just had to lump it, because the programmers didn't think it necessary, and thus the code to implement it never happened.
It's the effective banning of the concept because everyone now thinks exclusively as formatting internal to original source material that makes it almost impossible to even discuss adding markup on top of existing hypertext by a second or more parties.
We need markup. The old school kind, and its this deficiency that makes paper so bloody useful even now.
Google hates linguistic forking, and actively suppresses it by it's very nature. This means HTML will never be about markup, and we'll have to invent some new way of talking about it.
So here we are, 40 years after Ted Nelson, and we still use paper when we need markup.
Whitelist based security can't work in the long run, either. Because it forces you to decide what you want to trust, then you add that to the list. It does nothing about changing the nature of the default permissive environment.
For example, let's say you want to disable sound from a given task... you can't simply revoke it's access to the speaker... you have to do a lot of work to block it. This is what I mean by default permission. Any program that gets started is able to do anything you are allowed to do, thus if it has any hole, or gets confused, redirected, or tricked into doing evil, guess what... you're hosed.
The whitelist can't help. The only workable solution depends on a default deny environment.
It doesn't have to be this way. Security patches should be a rare event... and they would be if we had a proper security model underlying things. I can't believe how much acceptance there is of this bizarre state of affairs.
Let's face it, doing patches this often is like putting mattresses in the hole on the side of the Titanic. It merely delays the inevitable, slightly. We need to rip out the ineffective system we're gotten used to, and to move on.
No, I don't propose enumerating goodness. I propose that you tell the OS what capabilities you want to give to a program when you run it. Don't trust code, and you don't have to try to solve the halting problem.
The USER of the system is the one who should decide what's appropriate. They aren't likely to give permission to trash the OS if things are kept transparent and easy to understand.
Yes, the threats are real, but the solution that the "Cyber Warriors" came up with is crap. A much better solution than working around all the holes and patching them quicker is to simply rip out a bad design and replace it with a better one. Its not easy changing everyones OS, but it's cheaper in the long run.
Yes, enumerating badness is a bad idea... you'll aways be behind. Securing the OS by simply allowing the user what rights to grant a program at run time is a much more sane approach, don't you think?
Initiative #9. Define and develop enduring "leap-ahead" technology, strategies, and programs. One goal of the CNCI is to develop technologies that provide increases in cybersecurity by orders of magnitude above current systems and which can be deployed within 5 to 10 years. This initiative seeks to develop strategies and programs to enhance the component of the government R&D portfolio that pursues high-risk/high-payoff solutions to critical cybersecurity problems. The Federal Government has begun to outline Grand Challenges for the research community to help solve these difficult problems that require 'out of the box' thinking. In dealing with the private sector, the government is identifying and communicating common needs that should drive mutual investment in key research areas.
(Emphasis mine)
I propose instead that we consult the results of the previous R&D work that has been active in this area since the 1960s, and learn the lessons of problems already solved. This is low risk (as we've already paid for it), high payoff.
Let's get capability based security into the hands of the masses. This will remove their machines from the threat pool. It would also allow those inside the government to manage security in a much more granular (and thus more effective) manner.
This can be fixed, and it doesn't require a high risk, just due diligence, and hard work.
Let's just get a secure OS based on the capability object model into the hands of the masses, so we can fix the problem at it's source!
Make it possible for users to decide what capabilities a program is allowed to have before its run... they will actually make good choices if they have good tools.
The contract system is called capabilities, and it was first described in the 1960s. It's simply a kernel owned list of things a process is allowed to do.... if it's not in the list, the process doesn't get to do it.
Programmer skill is great, but you can't blame the programmer for bad tools either.
Why force the developers to worry so much about security? Why not instead provide a way to have a contract with the OS, which limits side effects to a known set of limitations? That would save a lot of grief, and let the developers get on with it.
Yes, better defaults could have been chosen 2 decades ago.
Now things have changed, and any system that doesn't let limits get set per task is insufficient. The current choices now are insuring 2 more decades of pain. I'm trying to educate people on the better options available, so that a better choice gets made.
It's now necessary to think of security with a much finer grain. The user is no longer the natural dividing line. It needs to be per task instance.
Actually, good security would be a GREAT selling point, if someone actually implemented it.
Security is the ability to run code without unwanted side effects. Windows, Mac, Linux do not offer a simple way to do this. The closest you can get is either Sandboxie on Windows, AppArmor on Linux, or setting up a VM per program.
If you offered a way to specify the limits of side effects on an application before and while it runs, you could make a ton of people very happy. I suspect there is some money to be made there as well.
Code has bugs, it always will. You need to reduce the attack surface, why not reduce it all the way down to the kernel of the OS? If you don't need to trust any of the users programs with the security of the whole system, you've solved a lot of problems.
Don't trust the users? Not a good idea. The users are the administrators these days.
Don't trust the internet? Well... it's a communications medium, just a set of tubes.
Testing the users might make sense if the Operating System had a reasonable security model. If you can't easily restrict a program to a small subset of your machine, you're forced to trust code you didn't write to get anything done.
Sure you could have a shell. You could leave it pretty much the way it is now, as far as the user is concerned. You let them choose what to feed to a program. The OS is responsible for enforcing the user's choices, they should be allowed to trash their machine if they so choose.
The difference is this would make it much more transparent, and you would KNOW you were feeding your system to a program, when you decided to do it.
Slashdot Mirror
The classical education of the Trivium is probably a much better fit for educating humans, as opposed to the factory farming methods of the 20th Century. It far better fits the developmental stages as they occur. I suspect as we move away from the need for uniform but low quality graduates, and try to get competitive intellectually in the world, the focus will naturally shift back to this superior form of education.
I received a 128 Gb Kingston SSDnow as a gift from a friend, to put in my laptop. The laptop had a 320 Gb hard drive, so I've had to not lug 2 years of photos around, but it's well worth it because this this is damned fast. Things that had 10 second times now are sub-second. The thing boots Windows 7 in less than 10 seconds.
Capacity is nice, but once you get past 40Gb or so, you only need it to store images and things in bulk. It's like having the speed of a SAN in a laptop. SSD is an order of magnitude faster as far as the user experience goes, and if you can get one for less than $200, it's well worth doing, IMHO.
Once the end users see this in action, the price/Gb won't matter to them, because responsiveness is the name of the game.
I'm not talking about the margins either... if HTML did what it said on the tin, you'd be able to highlight text someone else wrote, and more advanced versions would let you circle things, and photos, or whatever.
The ability to put a mark on top of something, to mark up 1 layer..
Paper allows markup, and so does papyrus. Clay tablets do as well, until they are dry or fired in a kiln.
Paperless "documents" can be made to support markup. Ted Nelson was talking about it in the 1960s. It's his inability to ship product (like Babbage before him) that kept his vision from being popularized.
When TBL got around to building the first web servers, and there arose a need for formatting, the term HTML got picked. The world was done a great disservice by the term HTML, which doesn't allow markup of text, let alone hypertext.
HTML has effectively banned discussion of old school markup, because for a large portion of cases, people didn't really need markup, they just wanted formatting, so they went along with the term. Anyone who wanted old school markup just had to lump it, because the programmers didn't think it necessary, and thus the code to implement it never happened.
It's the effective banning of the concept because everyone now thinks exclusively as formatting internal to original source material that makes it almost impossible to even discuss adding markup on top of existing hypertext by a second or more parties.
We need markup. The old school kind, and its this deficiency that makes paper so bloody useful even now.
Google hates linguistic forking, and actively suppresses it by it's very nature. This means HTML will never be about markup, and we'll have to invent some new way of talking about it.
So here we are, 40 years after Ted Nelson, and we still use paper when we need markup.
Whitelist based security can't work in the long run, either. Because it forces you to decide what you want to trust, then you add that to the list. It does nothing about changing the nature of the default permissive environment.
For example, let's say you want to disable sound from a given task... you can't simply revoke it's access to the speaker... you have to do a lot of work to block it. This is what I mean by default permission. Any program that gets started is able to do anything you are allowed to do, thus if it has any hole, or gets confused, redirected, or tricked into doing evil, guess what... you're hosed.
The whitelist can't help. The only workable solution depends on a default deny environment.
It doesn't have to be this way. Security patches should be a rare event... and they would be if we had a proper security model underlying things. I can't believe how much acceptance there is of this bizarre state of affairs.
Let's face it, doing patches this often is like putting mattresses in the hole on the side of the Titanic. It merely delays the inevitable, slightly. We need to rip out the ineffective system we're gotten used to, and to move on.
They will set them with a batch file, or a shortcut, most likely.
WOW... very insightful!
No, I don't propose enumerating goodness. I propose that you tell the OS what capabilities you want to give to a program when you run it. Don't trust code, and you don't have to try to solve the halting problem.
The USER of the system is the one who should decide what's appropriate. They aren't likely to give permission to trash the OS if things are kept transparent and easy to understand.
So this means I have to fight off the Chinese and the Military Industrial Complex at the same time? And do it in my spare time, with no budget?
Ok, so be it. 8)
Oh yes, it is possible to change this, and I'm going to do it, in my spare time, and without quitting my day job.
Yes, the threats are real, but the solution that the "Cyber Warriors" came up with is crap. A much better solution than working around all the holes and patching them quicker is to simply rip out a bad design and replace it with a better one. Its not easy changing everyones OS, but it's cheaper in the long run.
Yes, enumerating badness is a bad idea... you'll aways be behind. Securing the OS by simply allowing the user what rights to grant a program at run time is a much more sane approach, don't you think?
Initiative #9. Define and develop enduring "leap-ahead" technology, strategies, and programs. One goal of the CNCI is to develop technologies that provide increases in cybersecurity by orders of magnitude above current systems and which can be deployed within 5 to 10 years. This initiative seeks to develop strategies and programs to enhance the component of the government R&D portfolio that pursues high-risk/high-payoff solutions to critical cybersecurity problems. The Federal Government has begun to outline Grand Challenges for the research community to help solve these difficult problems that require 'out of the box' thinking. In dealing with the private sector, the government is identifying and communicating common needs that should drive mutual investment in key research areas.
(Emphasis mine)
I propose instead that we consult the results of the previous R&D work that has been active in this area since the 1960s, and learn the lessons of problems already solved. This is low risk (as we've already paid for it), high payoff.
Let's get capability based security into the hands of the masses. This will remove their machines from the threat pool. It would also allow those inside the government to manage security in a much more granular (and thus more effective) manner.
This can be fixed, and it doesn't require a high risk, just due diligence, and hard work.
Let's just get a secure OS based on the capability object model into the hands of the masses, so we can fix the problem at it's source!
Make it possible for users to decide what capabilities a program is allowed to have before its run... they will actually make good choices if they have good tools.
The contract system is called capabilities, and it was first described in the 1960s. It's simply a kernel owned list of things a process is allowed to do.... if it's not in the list, the process doesn't get to do it.
Programmer skill is great, but you can't blame the programmer for bad tools either.
Cool... some good ideas in here... I'll read this a few times to let it sink in.
Why force the developers to worry so much about security? Why not instead provide a way to have a contract with the OS, which limits side effects to a known set of limitations? That would save a lot of grief, and let the developers get on with it.
The reason users mess things up is that they have bad tools. There is no simple way to run something in a sandbox.
Yes, the registry sucks, for many reasons.
Yes, better defaults could have been chosen 2 decades ago.
Now things have changed, and any system that doesn't let limits get set per task is insufficient. The current choices now are insuring 2 more decades of pain. I'm trying to educate people on the better options available, so that a better choice gets made.
It's now necessary to think of security with a much finer grain. The user is no longer the natural dividing line. It needs to be per task instance.
Actually, good security would be a GREAT selling point, if someone actually implemented it.
Security is the ability to run code without unwanted side effects. Windows, Mac, Linux do not offer a simple way to do this. The closest you can get is either Sandboxie on Windows, AppArmor on Linux, or setting up a VM per program.
If you offered a way to specify the limits of side effects on an application before and while it runs, you could make a ton of people very happy. I suspect there is some money to be made there as well.
Code has bugs, it always will. You need to reduce the attack surface, why not reduce it all the way down to the kernel of the OS? If you don't need to trust any of the users programs with the security of the whole system, you've solved a lot of problems.
Don't trust the users? Not a good idea. The users are the administrators these days.
Don't trust the internet? Well... it's a communications medium, just a set of tubes.
Don't trust the programs? Great idea!
Testing the users might make sense if the Operating System had a reasonable security model. If you can't easily restrict a program to a small subset of your machine, you're forced to trust code you didn't write to get anything done.
Nobody should blame the users, if the OS sucks.
Sure you could have a shell. You could leave it pretty much the way it is now, as far as the user is concerned. You let them choose what to feed to a program. The OS is responsible for enforcing the user's choices, they should be allowed to trash their machine if they so choose.
The difference is this would make it much more transparent, and you would KNOW you were feeding your system to a program, when you decided to do it.