In the very least, I think it's a good idea to know what's going on behind the magic curtain...
Amen to that. I firmly believe that I am a better developer (not just coder) because at one time I DID write in machine code (it was a hardware computer course). I actually do know the major internals of a CPU, and how they react. Half-Adder anyone?
Re:We really need a different language
on
Secure Programming
·
· Score: 1
Now that said, the buffer overflow isn't the only security hole in the world, in fact more security holes come from very very high level, very abstract programming fallacies... such as for example the cookie exploit (it's a logical bug) that Hotmail had a while back.
There is a difference between a programmer error (buffer overflow) and a design problem.
If you can use a language which reduces programmer error, then you can spend more resources working on proper design.
By hiding the details behind a curtain, I think it is more likely problems will just get ignored
So you, um, write software in machine code?
Higher level languages exist because it is tedious and error prone to need to code every last bit (pun intended) of instructon required by the CPU to do any work. The higher level the language, the more insulated you are from the machine code.
Assembler required you to know registers, C and C++ require you to free memory resouces. Java requires you to open/close files. SQL requires you to know table and column names. Each step up requires less and less knowledge of the underlying system. And each step up is safer overall.
But ANY language can be written so it is insecure and/or buggy.
We will reach a day when the Star Trek type of information retrieval and manipulation is done. We are not there yet.
Without throwing an exception and crashing the program.
Which makes it unavailable for hacking. No program, no access.
Yes, a DoS will occur, but your site is safe.
Besides, a properly written Java app WILL have a try/catch block at some basic level to do a last ditch effort to intercept (and deal with) a normally fatal exception.
The original mainframes and minis had lights which were wired into the CPU registers. You could see what each register was doing by looking at the banks of blinking lights.
Computer teaching boxen had LED's which were wired into memory locations (you could choose which location via DIP switches). You could tell what each memory location held by looking at the banks of blinking lights.
Lossy compression means just that. Compression where part of the original information is lost.
Lossless compression means that ALL of the original information is preserved.
Lossless is used for storing information that MUST have completeness, such as programs, documents, source code, etc.
Lossless compression can be used where the missing information is not critical. For instance, the human eye cannot see 16 million individual colours. So a lossy compression (JPEG) can drop certain colours without apperant loss of image quality.
Similarily audio lossy compression drops things that the human ear cannot hear.
The amount of information lost can be altered, but the less information lost, the bigger the file, and the closer it is to the original.
You don't compile code to increase performance. Like the parent post said, you compile code so that the machine can understand it. Period.
Well, not actually.
PHP is an interpreted langauge, as is Perl. Both languages are complied "on the fly" by an interpreter. The compiled code only exists in memory. Once it has been compiled, then the computer runs it.
Compiled languages (such as C, C++, Pascal, etc) use a complier. The compiler produces compiled code, which the linker uses (along with libraries) to produce executables.
And there are C, etc, interpreters, and Perl, PHP compilers.
Thus decompiling a random binary may be very hard if you don't know what it was written in.
Nope.
Decompiling executables produces assembly code. Does not matter what the original language was.
Now, decompiling Java byte code does produce Java (albet with funning looking variable names), but that is only because Java byte code IS NOT an executable. It still needs a runtime environment (Java Virtual Machine, or JVM) to run the byte code on the native computer. Which is why Java can be compiled once, and can run in differring environments.
IBM made a big mistake by abandoning VAJ for Eclipse
Depends on your point of view. I too really liked VAJ. BUT, VAJ was several months behind on every new Java version release. It had to do with JIT compiling and allowing editing from within a debugger window.
Eclipse runs on different Java versions, and so does not need to be re-written when a new version comes out. And (since 1.4) you can edit fom within the debugger.
It cost IBM a LOT to adapt VAJ to a new Java version.
How exactly does one ask a yes/no question and then give a multiple choice answer?
You sir, are NOT a marketing guy....
Re:Good thing databases are perfect!
on
Databases and Privacy
·
· Score: 2, Interesting
And this is assuming that there are other areas where they may or may not be in alignment (e.g. abbreviations, type of info gathered, spelling variations etc.).
A lot of the variances can be correlated using fuzzy match technology. Everything from "sounds like", to matching on common variations (John and Johnathan, Bill and William), along with looking for initials, sex, location (address, city, postal code), and other commonalities.
The amount of information required to achieve a 95% match is not that great. With a sufficiently large cross-reference, decent matching rules (based on weighing personal factors), and enough computing power, making matches is not that difficult.
Given the sum of our personal factors, we are all unique to an amazing degree. Take a subset of those factors, and we are STILL unique to some large percentage. Spread out the information gathering (multiple databases) and you quickly become a specific individual rather than a possible number of individuals.
Go back to the originating databases, and now you have a personal profile of what you like and dislike.
Slashdot Mirror
In the very least, I think it's a good idea to know what's going on behind the magic curtain...
Amen to that. I firmly believe that I am a better developer (not just coder) because at one time I DID write in machine code (it was a hardware computer course). I actually do know the major internals of a CPU, and how they react. Half-Adder anyone?
Now that said, the buffer overflow isn't the only security hole in the world, in fact more security holes come from very very high level, very abstract programming fallacies... such as for example the cookie exploit (it's a logical bug) that Hotmail had a while back.
There is a difference between a programmer error (buffer overflow) and a design problem.
If you can use a language which reduces programmer error, then you can spend more resources working on proper design.
By hiding the details behind a curtain, I think it is more likely problems will just get ignored
So you, um, write software in machine code?
Higher level languages exist because it is tedious and error prone to need to code every last bit (pun intended) of instructon required by the CPU to do any work. The higher level the language, the more insulated you are from the machine code.
Assembler required you to know registers, C and C++ require you to free memory resouces. Java requires you to open/close files. SQL requires you to know table and column names. Each step up requires less and less knowledge of the underlying system. And each step up is safer overall.
But ANY language can be written so it is insecure and/or buggy.
We will reach a day when the Star Trek type of information retrieval and manipulation is done. We are not there yet.
Without throwing an exception and crashing the program.
Which makes it unavailable for hacking. No program, no access.
Yes, a DoS will occur, but your site is safe.
Besides, a properly written Java app WILL have a try/catch block at some basic level to do a last ditch effort to intercept (and deal with) a normally fatal exception.
Our proprietary protocols are good, theirs are bad. It boggles the mind....
And you have not heard of Microsoft?
Huh? Then how the heck can you use it?
It is obvious. You unplug the computer from the network and talk to yourself.
Thousands of dollars of technology so you can talk to yourself. This is progress!
The original mainframes and minis had lights which were wired into the CPU registers. You could see what each register was doing by looking at the banks of blinking lights.
Computer teaching boxen had LED's which were wired into memory locations (you could choose which location via DIP switches). You could tell what each memory location held by looking at the banks of blinking lights.
For the life of me, I can't think of one thing that is "out there" that cannot be had for much less on our resource-rich world.
micro-gravity
And the way that some processes work in micro-gravity.
the price of Freedom is eternal vigilantism.
Or you can simply EMP them. Blow the circuit, and then nobody can read the ID.
Shouldn't take too much if a pulse either, as they are so small.
Next big item on eBay: portable EMP generators.
Arg!
Just what we need...
[Role playing games], for example, got to where they had to have a book ship with the game.
And a good role playing game should emulate life in some aspect. If you are a General, then you should know something about being a General.
I can proudly state that after being alive for a number of years, I am actually good at being myself.
Now a game to play my role, would NEED to be shipped with a book. How else would you know how to play my role?
Two or three computers in the house, and pretty soon I will not need a hot water heater......
Its not the kind of thing that you can learn in 21 days from a Sams publishing book.
Damn!
That's not what lossy compression means at all.
Lossy compression means just that. Compression where part of the original information is lost.
Lossless compression means that ALL of the original information is preserved.
Lossless is used for storing information that MUST have completeness, such as programs, documents, source code, etc.
Lossless compression can be used where the missing information is not critical. For instance, the human eye cannot see 16 million individual colours. So a lossy compression (JPEG) can drop certain colours without apperant loss of image quality.
Similarily audio lossy compression drops things that the human ear cannot hear.
The amount of information lost can be altered, but the less information lost, the bigger the file, and the closer it is to the original.
You can actually justify $4500 for a personal shredder?
I just keep all my personal stuff for a year, then burn it during the annual camping trip.
And what is wrong with the store burning out the RFID? Using EMP should do it.
Similar to the current magnetic tags which are disabled at the counter.
I also third this idea.
There, we have three thirds. Now we have a whole idea.
Dude, if a community can't afford water, how is it going to afford e-anything?
That would be e-water.
Just hook up the device to a well, and you can pump it remotely. Needs its own IP address though, so it better be IPv6 so we don't run out....
Hmmm, by that logic, Perl source code is an executable. It's executable by a Perl interpreter.
The term "executable"'s conventional meaning is that the binary code can be executed by the CPU, not that an extra layer is required, such as a VM.
Sun's chip had that layer in firmware (ROM?, PROM?, EEPROM?) rather than software.
You don't compile code to increase performance. Like the parent post said, you compile code so that the machine can understand it. Period.
Well, not actually.
PHP is an interpreted langauge, as is Perl. Both languages are complied "on the fly" by an interpreter. The compiled code only exists in memory. Once it has been compiled, then the computer runs it.
Compiled languages (such as C, C++, Pascal, etc) use a complier. The compiler produces compiled code, which the linker uses (along with libraries) to produce executables.
And there are C, etc, interpreters, and Perl, PHP compilers.
Thus decompiling a random binary may be very hard if you don't know what it was written in.
Nope.
Decompiling executables produces assembly code. Does not matter what the original language was.
Now, decompiling Java byte code does produce Java (albet with funning looking variable names), but that is only because Java byte code IS NOT an executable. It still needs a runtime environment (Java Virtual Machine, or JVM) to run the byte code on the native computer. Which is why Java can be compiled once, and can run in differring environments.
Oops, yes you're right, it is not Javascript parsing. But...
In every OTHER browser which has Javascript turned on, the NOSCRIPT text is not shown, but in Opera, the text IS shown.
This is annoying, as the Javascript guidelines say that you should have a NOSCRIPT section.
How is Opera's JavaScript support "astoundingly bass-ackward"?
Well, it does not support the <noscript> tag.
IBM made a big mistake by abandoning VAJ for Eclipse
Depends on your point of view. I too really liked VAJ. BUT, VAJ was several months behind on every new Java version release. It had to do with JIT compiling and allowing editing from within a debugger window.
Eclipse runs on different Java versions, and so does not need to be re-written when a new version comes out. And (since 1.4) you can edit fom within the debugger.
It cost IBM a LOT to adapt VAJ to a new Java version.
How exactly does one ask a yes/no question and then give a multiple choice answer?
You sir, are NOT a marketing guy....
And this is assuming that there are other areas where they may or may not be in alignment (e.g. abbreviations, type of info gathered, spelling variations etc.).
A lot of the variances can be correlated using fuzzy match technology. Everything from "sounds like", to matching on common variations (John and Johnathan, Bill and William), along with looking for initials, sex, location (address, city, postal code), and other commonalities.
The amount of information required to achieve a 95% match is not that great. With a sufficiently large cross-reference, decent matching rules (based on weighing personal factors), and enough computing power, making matches is not that difficult.
Given the sum of our personal factors, we are all unique to an amazing degree. Take a subset of those factors, and we are STILL unique to some large percentage. Spread out the information gathering (multiple databases) and you quickly become a specific individual rather than a possible number of individuals.
Go back to the originating databases, and now you have a personal profile of what you like and dislike.