Really? From what I've gathered, Secure Boot first enters a Setup Mode where it will not load Drivers or Boot Loaders that are not signed with an appropriate digital signature. After the appropriate digital signature is entered and STORED in the firmware, UEFI enters User Mode where it will load Drivers and Boot Loaders that agree with the STORED digital signature.
I agree with the labeling assertion. If you call it Beef then it better, by God, be Beef. If it's got horsemeat in it as well then call it Beef and Horse Meat.
Like Beef and Turkey Hot Links being called Beef Hot Links. They're packed in "Natural Hog Casings" too so... call em Beef Turkey and Hog Hot Links.
Bad is such a subjective word. Bad as opposed to what? Bad how?
To me Bad code is: Uncommented, obfuscated, sphagetti, poor structure, follows no name or calling conventions, uses unnecessary tricks to accomplish it's goals, uses soon-to-be deprecated functions, code that just plain doesn't work and above all non-portable.
Guess they completely forgot the lessons supposedly learned on the LandWarrior project. Dump Windows with it's inherent insecure focus and go with an open system like Linux.
"Eventually, Oahu's Koolau and Waianae mountains will dwindle to little more than a flat, low-lying island like Midway." Considering how Midway is the remnant of an island created by the same volcanic hotspot that created the Hawaiian island chain, that's not surprising.
After reading many of these comments, I have gleaned the following reasons why many still run Windows: My friends run it. My boss makes me run it. Drivers. Games. MS specific programs not available on Linux.
Why not take some of that steam generated by the primary and run a failsafe turbine that doesn't generate electricity. It should just run pumps to keep the secondary cooling system running in the event of electrical failure. This way, even if the system has been flooded, cooling continues AND the hotter the primary gets, the faster the turbine will turn and the more cooling should be effected.
Well, here we have two opposing views of programming. On the one hand, we've got the Systems style programmer who can bootstrap a machine using binary digit displays and toggle switches. On the other hand we've got a Scriptor who uses canned programming.
There are pros and cons to both approaches: The Systems programmer will take longer to do the job, assuredly. But, when he's done, the result will be tight fast efficient code that will get the job done in a fraction of the time a script could. The Scriptor can probably hack together something that will get the job done but will not scale well. You'll need a supercomputer/Beowulf cluster to handle the load.
My opinion is: Use the scripting languages to prototype and make the final product a compilation like C/C++/PASCAL etc...
C++ is Object Oriented and it is also compiled. Best of both worlds.
I didn't think muzzleloaders... cannon or portables like pistols or smoothbores used fuses. Fuses are used for grenata.
I've never fired one myself but I've studied the issue a little. Pour charge down barrel or rip open paper cartridge and pour measured charge. Put wadding in barrel and finally the ball. Ram said ball down into the barrel with ramrod. Prime the pan with additional powder. Carefully pull back the hammer that has the flint into the cocked position. Aim, pull trigger. Hammer flies forward, flint strikes plate, sparks fall into pan igniting primer which burns through to the charge in the barrel. Click, sputter, BOOM!
Cannon works much the same way cept you touch a long match to the primer hole.
aussersterne said: "Yes, you can design something that's intentionally brain-dead, but still true to spec as a kind of intellectual exercise about extremes, but in the real world, the idea should be the opposite:
Stay true to the spec and try to robustly handle as many contingencies as is possible. Both developers should do this, filesystem and application, not "just" one or the other."
Applications DEPEND on the filesystem and other OS API's and services. Application programmers should NOT have to do anything but depend on the reliability of those OS components. The programmers of applications have enough to worry about without having to play hopscotch around OS irregularities - they've got enough to worry about working with the user's irregularities.
An implementation written according to the spec should inter-operate with any other app or implementation written according to that same spec. If problems with interoperability develop by any misinterpretation or stretching of the spec then the spec is not specific enough.
I have a toolbox at home that contains a pair of pliers.
These pliers have a formed handle that can be used as a screwdriver. I can pry with it, I can pound with it, I can pull small nails, grip, twist and an assortment of other jobs.
It's not particularly good at anything.
I also have a set of combination wrenches that work great for loosening nuts and bolts without buggering them. The pliers just can't do the job.
I have a hammer that can cleanly drive a nail and pull it out too. The pliers would be hard pressed to drive a finishing nail much less pull it.
Programming languages are tools.
Some are better at some tasks than others.
Recently, I have begun using Python. It is a very nice pair of pliers and the proper tool for one specific task - prototyping. It is so good at prototyping that the prototype often BECOMES the finished product. Python code is so close to pseudocode that often the code documents itself. Python is pervasive but not as much as C/C++/Java.
However, if I wanted absolute speed of computation, I'd make the finished product using C or C++.
If I wanted cross platform - Java is king.
Python is an excellent glue language for MultiLanguage Programming. Black box your components and call em with Python to tie it all together.
Or use another pair of pliers language that meets your needs.
What I'm getting at is: There is a proper tool for the job. Use the proper tool for the job. Have more than just a pair of pliers in your toolbox. Use the pliers if it's the right tool.
Slashdot Mirror
Really? From what I've gathered, Secure Boot first enters a Setup Mode where it will not load Drivers or Boot Loaders that are not signed with an appropriate digital signature. After the appropriate digital signature is entered and STORED in the firmware, UEFI enters User Mode where it will load Drivers and Boot Loaders that agree with the STORED digital signature.
Hello Bricksville!
It helps if she "wants" to participate. Also, a MMORPG with strong female characters and a good user community.
Hey, cellulose is technically a sugar - indigestible and good for fiber!
Even so, I'd prefer a real milkshake. :P
I agree with the labeling assertion. If you call it Beef then it better, by God, be Beef. If it's got horsemeat in it as well then call it Beef and Horse Meat.
Like Beef and Turkey Hot Links being called Beef Hot Links. They're packed in "Natural Hog Casings" too so... call em Beef Turkey and Hog Hot Links.
You mean to say that Microsoft is not adopting an existing specification but designing it's own proprietary one? Get outta here! I don't believe it!
Like they haven't done that before. :P
Bad is such a subjective word. Bad as opposed to what? Bad how?
To me Bad code is:
Uncommented, obfuscated, sphagetti, poor structure, follows no name or calling conventions, uses unnecessary tricks to accomplish it's goals, uses soon-to-be deprecated functions, code that just plain doesn't work and above all non-portable.
Looks like a Chinese Base in the Desert to me.
Guess they completely forgot the lessons supposedly learned on the LandWarrior project. Dump Windows with it's inherent insecure focus and go with an open system like Linux.
"Eventually, Oahu's Koolau and Waianae mountains will dwindle to little more than a flat, low-lying island like Midway."
Considering how Midway is the remnant of an island created by the same volcanic hotspot that created the Hawaiian island chain, that's not surprising.
C is intrinsic in my opinion. C++ can get very complicated.
I'd like to give it a go. :D
After reading many of these comments, I have gleaned the following reasons why many still run Windows:
My friends run it.
My boss makes me run it.
Drivers.
Games.
MS specific programs not available on Linux.
Pretty much what it's always been.
Last time I checked, TA worked pretty good in Wine.
I'd mod this comment up. Though I might nitpick the spelling. :)
>> 4,143,077 Texans live in poverty. 1,655,085 of them are children. http://www.census.gov/
The other some odd 2,487,922 are paying Texas traffic ticket SURCHARGES.
Seems kinda scary! All these mussels emitting Dihydrogen Monoxide - we all know how dangerous that is.
Why not take some of that steam generated by the primary and run a failsafe turbine that doesn't generate electricity. It should just run pumps to keep the secondary cooling system running in the event of electrical failure. This way, even if the system has been flooded, cooling continues AND the hotter the primary gets, the faster the turbine will turn and the more cooling should be effected.
Well, here we have two opposing views of programming. On the one hand, we've got the Systems style programmer who can bootstrap a machine using binary digit displays and toggle switches. On the other hand we've got a Scriptor who uses canned programming.
There are pros and cons to both approaches:
The Systems programmer will take longer to do the job, assuredly. But, when he's done, the result will be tight fast efficient code that will get the job done in a fraction of the time a script could.
The Scriptor can probably hack together something that will get the job done but will not scale well. You'll need a supercomputer/Beowulf cluster to handle the load.
My opinion is: Use the scripting languages to prototype and make the final product a compilation like C/C++/PASCAL etc...
C++ is Object Oriented and it is also compiled. Best of both worlds.
The basics; isn't that what PASCAL is for?
I think IT and Help Desk people should:
work in the basement.
all have personalized coffee mugs.
and have english accents.
No one expects the INQUISITION!
I didn't think muzzleloaders... cannon or portables like pistols or smoothbores used fuses. Fuses are used for grenata.
I've never fired one myself but I've studied the issue a little. Pour charge down barrel or rip open paper cartridge and pour measured charge. Put wadding in barrel and finally the ball. Ram said ball down into the barrel with ramrod. Prime the pan with additional powder. Carefully pull back the hammer that has the flint into the cocked position. Aim, pull trigger. Hammer flies forward, flint strikes plate, sparks fall into pan igniting primer which burns through to the charge in the barrel. Click, sputter, BOOM!
Cannon works much the same way cept you touch a long match to the primer hole.
I wonder if he makes his own black powder?
aussersterne said:
"Yes, you can design something that's intentionally brain-dead, but still true to spec as a kind of intellectual exercise about extremes, but in the real world, the idea should be the opposite:
Stay true to the spec and try to robustly handle as many contingencies as is possible. Both developers should do this, filesystem and application, not "just" one or the other."
Applications DEPEND on the filesystem and other OS API's and services. Application programmers should NOT have to do anything but depend on the reliability of those OS components. The programmers of applications have enough to worry about without having to play hopscotch around OS irregularities - they've got enough to worry about working with the user's irregularities.
An implementation written according to the spec should inter-operate with any other app or implementation written according to that same spec. If problems with interoperability develop by any misinterpretation or stretching of the spec then the spec is not specific enough.
There is a solution lurking somewhere.
so what do they do? They castrate him.
So very Planet of the Homo Sapiens.
I have a toolbox at home that contains a pair of pliers.
These pliers have a formed handle that can be used as a screwdriver. I can pry with it, I can pound with it, I can pull small nails, grip, twist and an assortment of other jobs.
It's not particularly good at anything.
I also have a set of combination wrenches that work great for loosening nuts and bolts without buggering them. The pliers just can't do the job.
I have a hammer that can cleanly drive a nail and pull it out too. The pliers would be hard pressed to drive a finishing nail much less pull it.
Programming languages are tools.
Some are better at some tasks than others.
Recently, I have begun using Python. It is a very nice pair of pliers and the proper tool for one specific task - prototyping. It is so good at prototyping that the prototype often BECOMES the finished product.
Python code is so close to pseudocode that often the code documents itself.
Python is pervasive but not as much as C/C++/Java.
However, if I wanted absolute speed of computation, I'd make the finished product using C or C++.
If I wanted cross platform - Java is king.
Python is an excellent glue language for MultiLanguage Programming. Black box your components and call em with Python to tie it all together.
Or use another pair of pliers language that meets your needs.
What I'm getting at is:
There is a proper tool for the job.
Use the proper tool for the job.
Have more than just a pair of pliers in your toolbox.
Use the pliers if it's the right tool.