"Non-trivial" doesn't even begin to describe the complexity of what goes on, to the point that even humans can't get it straight. Just the other day, I had to simultaneously corral no less than 5 university employees to figure out exactly what was going on with my pay situation.
It is easy to add complexity. It is extremely difficult to reduce unnecessary complexity. Open Source is not a magic bullet, it's not that simple, but something is not working right when it takes all 5, simultaneously, rather than any of the 5.
The students (who are renound at the undergrad level) wrote the school a new system and presented it to admininstration... at least twice... that is, wrote two different replacements. Admin didn't take either of them.
"In the land of the blind the one-eyed man is king." But not if Administration is blind. Administration is comparing course assignments with what the students are actually capable of doing. What the students are capable of doing when they organize themselves to do it. The one essential ingredient is that someone, singular and/or plural, must understand the problem domain.
Bit of a stretch, but I'd bet high-schoolers could actually pull it off.
There's a lot of politics in these things, and a lot of money flying around and buying opinion. As often as not the last thing those in power want is their own Computer Science people involved. That would queer the whole money flying around deal.
That's actually one of the strongest arguments for Open Source. Even if the software were more expensive for poorer quality and even if the support were inferior, you'd still come out ahead. Seems like Munich went for the more expensive Linux option.
"In fact, the high-profile business battle between the vendors complicates matters. Each company's software is known to interfere with the other's, to the detriment of customers like Stanford." Makes KDE and Gnome sound friendly to each other.
"For Handley, a big problem is that the software is designed to be used by public companies, not decentralized educational institutions. He notes that every ERP package he's worked with--Oracle, PeopleSoft and SAP--has a single ship-to address in the purchasing module. That's great for a company like IBM, which is organized around a central receiving unit" WHAT! IBM has one loading dock? He's been had.
.... I'm looking at this code and thinking, "That won't work!".... His eyes lit up
One student catches it... and his eyes light up. That says something about the normal state of things. I don't know what, but it ain't good.
"Your last instruction saved all the registers, three of which you've already overwritten?" In assembler the error is hard and immediate. In a "higher" level language the effect is more sublte and possibly delayed, harder to find, but just as serious. That error should be screaming even if you've never seen the particular assembler op codes before.
This is currently correct as Perl is currently implemented in C, however, there are optimizations that you can perform on Perl code which you cannot perform on the equivalent C code (simply because translating Perl to C is a lossy transformation). Therefore, it might be possible to achieve higher performance in some cases using Perl over C (if some parts of Perl were implemented in a more 'optimization-friendly' language).
Like Perl?
And now if the Perl program performs these optimizations on itself,...
Functional Programming has one very big thing going for it. Composition of functions is associative, but the different associations can have orders of magnitude differences in efficiency. A little bit of functional programming in "normal" languages can give some remarkable advantages.
All things being equal, any CPU-bound program written in C is highly likely to be faster than the same in Perl.
Depends. If the bulk of the CPU is in the program code as opposed to the library code, then C should be substantially faster than Perl. If the bulk of the CPU is in program code for C and in library code for Perl, then chances are high that the Perl is better coded and optimized. If the bulk of the CPU is in library code, then it depends on the libraries.
Formatted IO tends to be heavily interpreted and the odds favor Perl as being much faster.
I really am not comfortable with the idea of going back in time to revoke someone's doctorate unless academic misconduct led to its granting in the first place.
Agreed, but. Nothing definitive in the article, but the overall sense of it seems that it would be unlikely for him to start falsifying data when he got to Bell Labs. I am assuming that his work at Bell Labs was a continuation of the work he did in preparation for the degree.
And in asm, readability is even harder to obtain, so you'll probably avoid a lot of the sort of micro-optimizations a crazy compiler will do just so you can make sure the code works right.
Oh definitely! Good efficient asm will avoid most "optimizations" that compilers routinely do. You're after big gains not little gains. You happily lose 10 percent where it doesn't matter to gain a factor of 10 where it does matter.
My favorite example (from long, long ago) is hand-multiplying constants. If the timing does not matter, the code is uselessly obscured. If the timing does matter, that's the wrong solution and it only makes finding a viable solution that much harder.
I don't know what you mean by HAL, but I assume that you are trying to say that things like recursion and coroutines are hard to implement in an assembly language? If so, you are wrong.
Correct. HAL Higher Algorithmic Language is probably what I was thinking. Things like recursion and coroutines are nearly trivial in assembly language. There are things reasonably doable in assembly that are inconceivable in "higher" level languages. Recursive coroutines do not come naturally to the "higher" level languages. I have done coroutines in PL/I (with a little help, enough help to run FORTRAN in the context of PL/I ON ERROR;)
It's good to write readable code. But it's also good to write code that is reasonably optimized at the same time. No need to go to extremes, just don't do stupid things like passing around huge 4 kilobyte variables to functions and such (example I've seen). Pass a pointer instead. Or a reference. Just write smart code. You can still make readable code while making it optimal enough to scale pretty well. Only very, very rarely do you have something that needs to be super well optimized, and then you usually are better off writing the critical sections in machine code anyway.
Well put. Efficient systems are more the result of the absense of inefficiencies than the presence of efficiencies.
To put it more concretely, couldn't I just write a program in C that does EXACTLY what the Perl program does, down to the last data structure?
Oh yes. Furthermore, if you can analyse what is doing the heavy lifting and somehow, anyhow, gain an advantage, you can make a program which is overall faster, but everywhere except the heavy lifting, is significantly slower.
You could even take it a step further. You could write an exact duplicate of the Perl program, leave out the parts of the Perl interpreter that you don't use
Now you reach the turf where the hackers and home-grown systems have an unfair advantage. About three significant problems that you don't have to worry about is sufficient for poor talent to triumph. Downsides are that you wind up with archaic systems that no one dares touch and circumstances can change so that the non-problems now become problems.
To me a beautiful piece of code is one that is so simple it does exactly what it needs, and nothing more, and it reads like pseudo-code. Minimalism is the name of the game.
From an old fart who likes assembly language, total agreement. Assuming the primary goal is performance, the blunt reality is that about 90% of the code is irrelevant as to impacting that performance. Any screweys in that code, particularly trying to "improve" performance, will have indirect deletorious effects on that performance.
Disclaimer: I learned to debug before I learned to code. With extremely few exceptions, machine code performs exactly as advertised. When things are not exactly as they should be, it helps to be able to see exactly what is going on.
Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.
Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.
Default hiding of file extensions. Is that still the default?
The one that allows execution of arbritray code on your computer. Seems like Microsoft keeps fixing it but it doesn't stay fixed. Of course Linux counts each of them separately;)
This doesn't sound like just DNS, FTP and proxy services to me. McDonalds has been using computers for a long, long time and Novell is business-savy enough to not let loose their customer's plans.
"SUSE LINUX Enterprise Server enables us to deliver a functional, flexible, efficient, and yet efficient infrastructure," says Trepl.
Apache as web server and JRun or Tomcat enable the implementation of static HTML contents as well as dynamic Java-based applications without having to resort to overly large solutions. The utilized Oracle9i database is certified for SUSE LINUX Enterprise Server.
According to Trepl, "Our current solution can be expanded at any time. This is possible due to the low price, the flexibility of a Linux solution, and the certification of SUSE LINUX Enterprise Server for solutions such as Oracle9i. Thus, there is no upper limit."
If the KKK (Christian extremists) were lynching people still, you can guarantee you'd have Christians across the country outraged by this and telling everyone.
Some. From a distance. Almost never from the same social set as the members of the KKK.
It's easy to be morally outraged at them, almost impossible to be morally outraged at us.
If you're going to worry about security, do it on the machines. Leave the network infrastructure alone. Rawk!
Right on. I'd put securing wireless in about the same category as securing streets and sidewalks. Now imagine downtown with toll sidewalks. Society has always had ways to deal with disrupters of the peace. Internet shouldn't be any different.
"The structure of mathematical journals creates the impression that mathematics is fragmented into unrelated disciplines. The underlying unity of mathematics is however maintained by problems which span these disciplines.... The Riemann hypothesis is listed as an important link between algebra and analysis."
The significance may be more in the mathematical machinery required to prove it than in the result itself.
So, you're trapped into using a buggy and remotely-exploitable windows-only fat client for certain applications. But they tell you it's "web based," and that makes it ok?
Bingo! That seems to be the logic employed. Something like some implies all. Considering, it's a wonder it works as well as it does.
Servers exploited by malicious clients. (Coming soon to a web page near you;)
Really, if it is important to validate your data you need to do it on the server! I don't care much about security, but this should be obvious. Coding the client to catch all the errors (in all combinations) has to be difficult and trusting the results of this unknown has to be stupid. What's incredible is security-related sites requiring that scripting be turned on. Anyone seriously expect users to take security seriously in that context?
I've seen "consultants" "erase" a disk by just destroying the partition table. And at the time they were making a whole lot more money than me.
Writing to all of the disk even once takes time, lots of time. Real fast and it won't boot. (Of course re-partitioning stands a good chance of bringing everything back;)
Slashdot Mirror
"Non-trivial" doesn't even begin to describe the complexity of what goes on, to the point that even humans can't get it straight. Just the other day, I had to simultaneously corral no less than 5 university employees to figure out exactly what was going on with my pay situation.
It is easy to add complexity. It is extremely difficult to reduce unnecessary complexity. Open Source is not a magic bullet, it's not that simple, but something is not working right when it takes all 5, simultaneously, rather than any of the 5.
The students (who are renound at the undergrad level) wrote the school a new system and presented it to admininstration... at least twice... that is, wrote two different replacements. Admin didn't take either of them.
"In the land of the blind the one-eyed man is king."
But not if Administration is blind.
Administration is comparing course assignments with what the students are actually capable of doing. What the students are capable of doing when they organize themselves to do it. The one essential ingredient is that someone, singular and/or plural, must understand the problem domain.
Bit of a stretch, but I'd bet high-schoolers could actually pull it off.
There's a lot of politics in these things, and a lot of money flying around and buying opinion. As often as not the last thing those in power want is their own Computer Science people involved. That would queer the whole money flying around deal.
That's actually one of the strongest arguments for Open Source.
Even if the software were more expensive for poorer quality and even if the support were inferior, you'd still come out ahead. Seems like Munich went for the more expensive Linux option.
"In fact, the high-profile business battle between the vendors complicates matters. Each company's software is known to interfere with the other's, to the detriment of customers like Stanford."
Makes KDE and Gnome sound friendly to each other.
"For Handley, a big problem is that the software is designed to be used by public companies, not decentralized educational institutions. He notes that every ERP package he's worked with--Oracle, PeopleSoft and SAP--has a single ship-to address in the purchasing module. That's great for a company like IBM, which is organized around a central receiving unit"
WHAT! IBM has one loading dock? He's been had.
.... I'm looking at this code and thinking, "That won't work!". ... His eyes lit up
... and his eyes light up.
One student catches it
That says something about the normal state of things. I don't know what, but it ain't good.
"Your last instruction saved all the registers, three of which you've already overwritten?"
In assembler the error is hard and immediate. In a "higher" level language the effect is more sublte and possibly delayed, harder to find, but just as serious. That error should be screaming even if you've never seen the particular assembler op codes before.
This is currently correct as Perl is currently implemented in C, however, there are optimizations that you can perform on Perl code which you cannot perform on the equivalent C code (simply because translating Perl to C is a lossy transformation). Therefore, it might be possible to achieve higher performance in some cases using Perl over C (if some parts of Perl were implemented in a more 'optimization-friendly' language).
...
Like Perl?
And now if the Perl program performs these optimizations on itself,
Functional Programming has one very big thing going for it. Composition of functions is associative, but the different associations can have orders of magnitude differences in efficiency. A little bit of functional programming in "normal" languages can give some remarkable advantages.
All things being equal, any CPU-bound program written in C is highly likely to be faster than the same in Perl.
Depends.
If the bulk of the CPU is in the program code as opposed to the library code, then C should be substantially faster than Perl.
If the bulk of the CPU is in program code for C and in library code for Perl, then chances are high that the Perl is better coded and optimized.
If the bulk of the CPU is in library code, then it depends on the libraries.
Formatted IO tends to be heavily interpreted and the odds favor Perl as being much faster.
I really am not comfortable with the idea of going back in time to revoke someone's doctorate unless academic misconduct led to its granting in the first place.
Agreed, but.
Nothing definitive in the article, but the overall sense of it seems that it would be unlikely for him to start falsifying data when he got to Bell Labs. I am assuming that his work at Bell Labs was a continuation of the work he did in preparation for the degree.
And in asm, readability is even harder to obtain, so you'll probably avoid a lot of the sort of micro-optimizations a crazy compiler will do just so you can make sure the code works right.
Oh definitely!
Good efficient asm will avoid most "optimizations" that compilers routinely do. You're after big gains not little gains. You happily lose 10 percent where it doesn't matter to gain a factor of 10 where it does matter.
My favorite example (from long, long ago) is hand-multiplying constants.
If the timing does not matter, the code is uselessly obscured.
If the timing does matter, that's the wrong solution and it only makes finding a viable solution that much harder.
I don't know what you mean by HAL, but I assume that you are trying to say that things like recursion and coroutines are hard to implement in an assembly language? If so, you are wrong.
Correct.
HAL Higher Algorithmic Language is probably what I was thinking.
Things like recursion and coroutines are nearly trivial in assembly language.
There are things reasonably doable in assembly that are inconceivable in "higher" level languages.
Recursive coroutines do not come naturally to the "higher" level languages.
I have done coroutines in PL/I (with a little help, enough help to run FORTRAN in the context of PL/I ON ERROR;)
It's good to write readable code. But it's also good to write code that is reasonably optimized at the same time. No need to go to extremes, just don't do stupid things like passing around huge 4 kilobyte variables to functions and such (example I've seen). Pass a pointer instead. Or a reference. Just write smart code. You can still make readable code while making it optimal enough to scale pretty well. Only very, very rarely do you have something that needs to be super well optimized, and then you usually are better off writing the critical sections in machine code anyway.
Well put. Efficient systems are more the result of the absense of inefficiencies than the presence of efficiencies.
To put it more concretely, couldn't I just write a program in C that does EXACTLY what the Perl program does, down to the last data structure?
Oh yes. Furthermore, if you can analyse what is doing the heavy lifting and somehow, anyhow, gain an advantage, you can make a program which is overall faster, but everywhere except the heavy lifting, is significantly slower.
You could even take it a step further. You could write an exact duplicate of the Perl program, leave out the parts of the Perl interpreter that you don't use
Now you reach the turf where the hackers and home-grown systems have an unfair advantage. About three significant problems that you don't have to worry about is sufficient for poor talent to triumph. Downsides are that you wind up with archaic systems that no one dares touch and circumstances can change so that the non-problems now become problems.
Why does use of assembly preclude thinking in terms of functions and algorithms?
Well, it shouldn't.
Just try implementing recursive co-routines in a HAL.
To me a beautiful piece of code is one that is so simple it does exactly what it needs, and nothing more, and it reads like pseudo-code. Minimalism is the name of the game.
From an old fart who likes assembly language, total agreement.
Assuming the primary goal is performance, the blunt reality is that about 90% of the code is irrelevant as to impacting that performance. Any screweys in that code, particularly trying to "improve" performance, will have indirect deletorious effects on that performance.
Absolutely.
Disclaimer: I learned to debug before I learned to code.
With extremely few exceptions, machine code performs exactly as advertised. When things are not exactly as they should be, it helps to be able to see exactly what is going on.
Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.
Responsiveness: On average, Microsoft had a fix available 25 days after a security issue was publicly disclosed.
Default hiding of file extensions.
Is that still the default?
The one that allows execution of arbritray code on your computer.
Seems like Microsoft keeps fixing it but it doesn't stay fixed.
Of course Linux counts each of them separately;)
Probably went along for the ride with "enable the implementation of static HTML contents as well as dynamic Java-based applications".
Possibly translation error. Possibly they're excited but don't want to give too much away as to what their plans are.
Not exactly a great image for a high-tech customer reference.
I'd disagree. McDonalds was into computers and automation long before most Slashdotters were born. It's not just Burger King that imitates McDonalds.
This doesn't sound like just DNS, FTP and proxy services to me.
McDonalds has been using computers for a long, long time and Novell is business-savy enough to not let loose their customer's plans.
"SUSE LINUX Enterprise Server enables us to deliver a functional, flexible, efficient, and yet efficient infrastructure," says Trepl.
Apache as web server and JRun or Tomcat enable the implementation of static HTML contents as well as dynamic Java-based applications without having to resort to overly large solutions. The utilized Oracle9i database is certified for SUSE LINUX Enterprise Server.
According to Trepl, "Our current solution can be expanded at any time. This is possible due to the low price, the flexibility of a Linux solution, and the certification of SUSE LINUX Enterprise Server for solutions such as Oracle9i. Thus, there is no upper limit."
If the KKK (Christian extremists) were lynching people still, you can guarantee you'd have Christians across the country outraged by this and telling everyone.
Some. From a distance. Almost never from the same social set as the members of the KKK.
It's easy to be morally outraged at them, almost impossible to be morally outraged at us.
If you're going to worry about security, do it on the machines. Leave the network infrastructure alone. Rawk!
Right on. I'd put securing wireless in about the same category as securing streets and sidewalks. Now imagine downtown with toll sidewalks. Society has always had ways to deal with disrupters of the peace. Internet shouldn't be any different.
"The structure of mathematical journals creates the impression that mathematics is fragmented into unrelated disciplines. The underlying unity of mathematics is however maintained by problems which span these disciplines. ... The Riemann hypothesis is listed as an important link between algebra and analysis."
The significance may be more in the mathematical machinery required to prove it than in the result itself.
So, you're trapped into using a buggy and remotely-exploitable windows-only fat client for certain applications. But they tell you it's "web based," and that makes it ok?
Bingo! That seems to be the logic employed.
Something like some implies all.
Considering, it's a wonder it works as well as it does.
Yes, because you can't trust the client!
Servers exploited by malicious clients.
(Coming soon to a web page near you;)
Really, if it is important to validate your data you need to do it on the server!
I don't care much about security, but this should be obvious. Coding the client to catch all the errors (in all combinations) has to be difficult and trusting the results of this unknown has to be stupid. What's incredible is security-related sites requiring that scripting be turned on. Anyone seriously expect users to take security seriously in that context?
I've seen "consultants" "erase" a disk by just destroying the partition table. And at the time they were making a whole lot more money than me.
Writing to all of the disk even once takes time, lots of time.
Real fast and it won't boot.
(Of course re-partitioning stands a good chance of bringing everything back;)
what i want to know is what program did this firm use to extract all this data off the drives?
/dev/hda | less
strings
will give you some idea what's on the drive
I'm sure with a bit of effort there are much better means.