The discovery of this program by Northwestern University journalism student Laura McGann has added fuel to the debate about the Education Department's proposal to start a new database tracking the academic progress of all students."
That's a great idea. It will make it a lot easier in the future to track down people who took subversive classes, classes from subversive professors, or classes with other subversives.
Of course, that does make it a little tricky today for students to figure out who will be a subversive in twenty or thirty years. I know that back when I was in University (yes, it was during Vietnam) I would have bet that the people on the wrong side of a Senate subcommittee would have been the ones throwing Molotov cocktails. I would have been wrong, though. They're the ones conducting the Inquisition now.
Security is going to ask you about the xray-opaque cans and metal strips, get a lame excuse, and be told to either check them or throw them out, if they don't flat-out arrest you for trying to smuggle something.
You're making my point: the whole process assumes that the Bad Guys are so stupid that they're going to bring their thermite onboard as a jar of metallic powder, metallic paste (complete with nitrate igniter), or some such. Sheesh.
In case you haven't noticed, any (large) number of ordinary items are made out of sintered metals. Plaques, statuettes, etc. are just a few of the possibilities, and Al+Fe3O4 can be pressed with a binder into similar shapes. The Mg ignition wire is just that: a fine wire that can be hidden in dang near anything and only needs a modest current to light off.
Once that thermite starts up, there is nothing that can stop it from getting to the plane's skin -- which is aluminum. Would you care to guess what happens when thermite slag at a few thousand degrees C comes into contact with sheet aluminum? With a forced-air feed at several hundred Kph?
The TSA and equivalents are still doing PR instead of real screening because they know that there's no realistic way to do real screening against real threats. There are just too freaking many ways to do violence. It's telling that there aren't any serious "Red Teams" coming up with potential threats -- instead they just keep reacting to the latest ones the Bad Guys used and hope those same Bad Guys are too stupid to come up with any of the thousands that a freshman engineering student could write up in a half-hour quiz.
You want Red Team? Have the CalTech prank-of-the-year be an airplane removal. You'd have hundreds in a matter of hours.
Proof of point: tell me how they're going to stop people from taking ferrite, aluminum, and magnesium on planes.
As I read it, Microsoft has declared that as of their next release, they simply won't allow unsigned drivers and other kernel-level code to run. Which, according to quite a few hardware vendors, means enough expense to be prohibitive; those same vendors today simply provide instructions to ignore "this code isn't signed" warnings.
Well, this hack lets those vendors continue as they bear.
The posts about "well, DUH! you need admin privs" is beside the point because driver (etc) installations always have. The news is that Microsoft has been trying to change that, and (at least for now) failed.
they seek to convince hackers and security researchers to work with, not against, them
In other words, "Shut the fuck up about all of the stuff you find until we quietly issue a patch. If we get around to it. Oh, and here's an NDA that gives us your nads if you talk in your sleep."
After thirty-plus years in engineering I don't see anything new here. Then again, I mostly worked in small companies or small-team groups in medium-sized companies.
What this may be showing is the trend towards smaller companies (already noted elsewhere) or larger companies using smaller, self-organized teams rather than groups of hundreds or thousands who have several layers of management for one project. My current project team has less than twenty staff assigned, including support and management -- and it's the largest team I've worked on since 1979.
To fill out your item [2], the name of the company was Lattice. MS bought the Lattice compiler and renamed it MS C.
It was an early example of the MS method of software development: buy out someone who has a viable product and do a much better job of marketing that product.
Except that MS didn't buy out Lattice. They had a marketing agreement where MS was allowed to relable "Lattice C" as "Microsoft C" and the result was that MS sales took over. When the agreement came up for renewal, MS pulled out their reimplementation and told Lattice thank you very much but we don't need you any more.
Lattice lingered for a few years after that before vanishing, but they were never the company they had been.
Microchip has designed their latest micros around their compiler ( I think it is based on gnu c).. While not done Do {Compile, look for ways to optimize cpu or compiler};
Microchip's compiler is indeed based on gcc.
As for "latest" there are several and you may be overstating the case.
What was true 20 years ago is still true today, well written code in a low level language tailored to how the computer actually works will always be faster than a higher level environment.
And what was true 20 years ago was for a different world.
You may have the time to lovingly hand-code an initialization routine, making sure at each line to check the scoreboard for the multiple execution engines on each stage of the CPU's pipeline so as to avoid congestion stalls. I'm sure that you can crank out as many as ten lines a day that way.
Similarly, Bob Pease also lovingly calculates the equations for analog circuits, eschewing the use of simulators.
The rest of us are content to let that massive bookkeeping chore to computers, because hand-calculating the intersymbol interference in a multi-gigabit signaling environment (with adaptive decision-feedback equalization) in the face of multiple parametric variables would take until the next millennium.
The same goes for scoreboarding multiple-issue deep-pipeline processors with branch prediction. You just do not want to go there by hand, but compilers do it easily.
Well, generally you'll have faster code if you code it in assembly.
I wouldn't even grant that in the general case.
Amazingly far back (try the 80s) a professor friend of mine had a marvelous example of compiler-generated code where the compiler had done such an amazing job of optimising register use that you had to trace through more than 20 pages of assembler output with colored markers to trace from where the register was loaded to where it was used.
No way I would ever have the huevos to code that way in assembler.
On a RISC machine or (Heaven help us) the Itanic it gets lots worse.
Twenty years ago we were still in the midst of the "language wars" and this was a hot topic. The argument then, as now, was whether a high-level language could be compiled as efficiently as a low-level language like C [1].
Well, we ran our own tests. We took a sizable chunk of supposedly well-written time-critical code that the gang had produced in what was later to become Microsoft C [2] and rewrote the same modules in Logitech Modula-2. The upshot was that the M2 code was measurably faster, smaller, and on examination better optimized. Apparently the C compiler was handicapped by essentially having to figure out what the programmer meant with a long string of low-level expressions.
Extrapolations to today are left to the reader.
[1] I used to comment that C is not a high-level language, which would induce elevated blood pressure in C programmers. After working them up, I'd bet beer money on it -- and then trot out K&R, which contains the exact quote, "C is not a high-level language."
[2] MS originally relabled another company's C complier under license (I forget their name; they were an early object lesson.)
I think you're going to have a bitch of a time selling that idea to management. They live and die by quarterly goals, and their goal is to get this turkey out the door this quarter. Maintenance is someone else's problem, assuming we make it that far.
Of course it's stupid and short-sighted. We sacked all of the people who wasted time on anything but the immediate requirements.
But, the conundrum here is that one of Microsoft's biggest assets is their market penetration. Legal or not, a PC running Windows *tends* to be a PC not running Linux. If you suddenly force all the non-legal users off your platform, you're forcing the to use something else. Which means, in turn, more demand for OpenOffice, games on Linux, GAIM, ad infinitium - until there is a more, better, complete Linux end-user software stack to seriously compete with Windows.
I'm sure that somewhere there is someone who will abandon MSWindows over this. Maybe two.
I'm also sure that Microsoft has a very good idea how many there actually are and is isn't concerned.
In other words, they have the whip hand and this is just them cracking the whip.
As a business owner I wouldn't want to risk having one of my employees PCs out of commission due to what could be an honest mistake or omission on my part.
So instead you'll take it out of commission yourself? That would certainly make Steve Ballmer sweat wouldn't it?
Face it -- Microsoft knows quite well how much market this will cost them and it's too low to be a concern even to the ultimate "there can be only one" company. Even the false positives (shutting down legit systems) will end up being a net revenue enhancer.
What are you going to do about it? Hold your breath until you turn blue?
No, I'm not trolling -- the reality is that Microsoft has the whip hand and all the sound and fury is coming from people who know that in the end they're going to do as they've been told.
That's a great idea. It will make it a lot easier in the future to track down people who took subversive classes, classes from subversive professors, or classes with other subversives.
Of course, that does make it a little tricky today for students to figure out who will be a subversive in twenty or thirty years. I know that back when I was in University (yes, it was during Vietnam) I would have bet that the people on the wrong side of a Senate subcommittee would have been the ones throwing Molotov cocktails. I would have been wrong, though. They're the ones conducting the Inquisition now.
Well, nothing in life is certain.
Keep in mind that their own management can't get their own products to work.
In case you haven't noticed, any (large) number of ordinary items are made out of sintered metals. Plaques, statuettes, etc. are just a few of the possibilities, and Al+Fe3O4 can be pressed with a binder into similar shapes. The Mg ignition wire is just that: a fine wire that can be hidden in dang near anything and only needs a modest current to light off.
Once that thermite starts up, there is nothing that can stop it from getting to the plane's skin -- which is aluminum. Would you care to guess what happens when thermite slag at a few thousand degrees C comes into contact with sheet aluminum? With a forced-air feed at several hundred Kph?
You'd see that one from orbit. In daylight.
You want Red Team? Have the CalTech prank-of-the-year be an airplane removal. You'd have hundreds in a matter of hours.
Proof of point: tell me how they're going to stop people from taking ferrite, aluminum, and magnesium on planes.
Instead we get programs to prevent baby bottles.
From the description, it's more like "Apollo on Viagra."
Hey -- someone else remembers. I wondered.
Silly, that's because a cat owns the Internet.
As I read it, Microsoft has declared that as of their next release, they simply won't allow unsigned drivers and other kernel-level code to run. Which, according to quite a few hardware vendors, means enough expense to be prohibitive; those same vendors today simply provide instructions to ignore "this code isn't signed" warnings.
Well, this hack lets those vendors continue as they bear.
The posts about "well, DUH! you need admin privs" is beside the point because driver (etc) installations always have. The news is that Microsoft has been trying to change that, and (at least for now) failed.
In other words, "Shut the fuck up about all of the stuff you find until we quietly issue a patch. If we get around to it. Oh, and here's an NDA that gives us your nads if you talk in your sleep."
What this may be showing is the trend towards smaller companies (already noted elsewhere) or larger companies using smaller, self-organized teams rather than groups of hundreds or thousands who have several layers of management for one project. My current project team has less than twenty staff assigned, including support and management -- and it's the largest team I've worked on since 1979.
The market's view of this is visible from the fact that ATI is up and AMD is waaaay down.
Lattice lingered for a few years after that before vanishing, but they were never the company they had been.
As for "latest" there are several and you may be overstating the case.
You may have the time to lovingly hand-code an initialization routine, making sure at each line to check the scoreboard for the multiple execution engines on each stage of the CPU's pipeline so as to avoid congestion stalls. I'm sure that you can crank out as many as ten lines a day that way.
Similarly, Bob Pease also lovingly calculates the equations for analog circuits, eschewing the use of simulators.
The rest of us are content to let that massive bookkeeping chore to computers, because hand-calculating the intersymbol interference in a multi-gigabit signaling environment (with adaptive decision-feedback equalization) in the face of multiple parametric variables would take until the next millennium.
The same goes for scoreboarding multiple-issue deep-pipeline processors with branch prediction. You just do not want to go there by hand, but compilers do it easily.
Amazingly far back (try the 80s) a professor friend of mine had a marvelous example of compiler-generated code where the compiler had done such an amazing job of optimising register use that you had to trace through more than 20 pages of assembler output with colored markers to trace from where the register was loaded to where it was used.
No way I would ever have the huevos to code that way in assembler. On a RISC machine or (Heaven help us) the Itanic it gets lots worse.
One of my favorite early examples of the consequences of being Microsoft's "special friend."
Well, we ran our own tests. We took a sizable chunk of supposedly well-written time-critical code that the gang had produced in what was later to become Microsoft C [2] and rewrote the same modules in Logitech Modula-2. The upshot was that the M2 code was measurably faster, smaller, and on examination better optimized. Apparently the C compiler was handicapped by essentially having to figure out what the programmer meant with a long string of low-level expressions.
Extrapolations to today are left to the reader.
[1] I used to comment that C is not a high-level language, which would induce elevated blood pressure in C programmers. After working them up, I'd bet beer money on it -- and then trot out K&R, which contains the exact quote, "C is not a high-level language."
[2] MS originally relabled another company's C complier under license (I forget their name; they were an early object lesson.)
Of was that a different Senate?
Of course it's stupid and short-sighted. We sacked all of the people who wasted time on anything but the immediate requirements.
is what smartass decided to name it after a starch?
http://news.zdnet.com/2100-9584_22-6091780.html I also saw some of the same numbers in another place but frankly forget where.
I'm also sure that Microsoft has a very good idea how many there actually are and is isn't concerned.
In other words, they have the whip hand and this is just them cracking the whip.
Face it -- Microsoft knows quite well how much market this will cost them and it's too low to be a concern even to the ultimate "there can be only one" company. Even the false positives (shutting down legit systems) will end up being a net revenue enhancer.
What are you going to do about it? Hold your breath until you turn blue?
No, I'm not trolling -- the reality is that Microsoft has the whip hand and all the sound and fury is coming from people who know that in the end they're going to do as they've been told.