My question for you is: Will it work over the Internet as is now, or do all the routers in between the source and the destinations have to be specially set up to handle the multicasting traffic? I did a number of multicast experiments a couple years ago and found multicast to be unusable over the net because the routers dropped all the packets.
In the case of a LCD cell, the required charge on the cell is very very tiny. Therefore the impulse current required is miniscule.
Once I was playing around with a bare dot matrix LCD panel - looks just like a piece of glass. I could make the cells go black by holding it on one side where the almost transparent rows of wires were and waving it in front of a computer monitor or even near someone else. The static charge was enough to make the cells dark - And stayed that way for over half an hour.
As others have pointed out, the LCD stops the transmission of light when voltage is applied, hence giving you black.
But one other nit-pick: "I don't understand why you need power to produce black" - No you don't need power. You need Voltage. The LCD cell acts like a capacitor and does not pass DC electricity though it. So no current, and hence no power used.
Leakage would probably be in the micro-amp range.
However it is not your job to test the security of someone else's system.
It is like breaking into a bank's safe in order to demonstrate the failure of their security system. Very unwise. Don't do it.
I hope though that they eventually DO have different charges and penalties for different hacking actions. Unfortunately, most law-makers are clueless with regards to technology.
My original point was just that hacking CAN be worse than murder. And it doesn't have to be a military site either - an evil hacker modifying www.cnn.com could cause huge effects.
My wish is that sysadmins who are negligent in keeping their system secure share in the responsibility of the damage that occurs when it is hacked.
If I leave my car parked with the engine running and the door opened for half an hour, I think the insurance company will blame me just as much as the thief. If an admin runs IIS and ignores the security patches, he should get blamed as well.
But it has happened indirectly where some idiot connects their insecure WinNT machine to the internal secure network. Once someone hacks the insecure machine he has access to the secure network.
In fact, with a very good low noise cd player (which is 16 bits) and a 24 bit A/D converter you will get a result that is almost perfect - the only possible tiny glitches would be from slight differences in the sample rates.
--jeff
Situation normal at microsoft
on
XBox Delayed
·
· Score: 1
They've ALWAYS announced products before they were even started in order to get people to hold off buying the competitor's products. "Oh, but microsoft is coming out with a product very soon that will be better than your product". Then 'very soon' turns into delays and more delays mixed with more hype as they actually start to desgin the product. And people are still holding off buying the competitor's product. Eventually microsoft's product is finally released (with many bugs) and everyone is SO HAPPY to buy their long awaited thing. In the meantime, the competition has suffered. Sometimes the competition suffers enough to be bought up by microsoft for dirt cheap.
Ever hear about 'Microsoft for Cable TV?'
They failed at that - spent huge money on it, didn't even get a product out the door. Then they bought WebTV instead for cheap.
I think it is time to GIVE UP the hacker title. The original meaning is lost forever. Call yourself a 'Computer Programmer' instead and everyone will be happier and will not be confused anymore.
Everyone knows that Hackers are all terrorists, anyways!
#1 Only government approved crypto (with content copy protection built in as well as a back door) would be allowed over communication lines.
#2 With government being friendly to the law-breaking Microsoft, only Windows XP2 and Solaris will support this crypto.
#3 The crypto will be closed source. Therefore any GNU GPL'd O/S will be illegal.
#4 The system will be quickly and silently hacked and Bin Laden and his terrorist friends can wreak havoc on our economy and people AGAIN with a simple telephone call.
Just because a law is stupid and ineffectual does not mean it won't happen.
GCC does NOT contain all languages in one binary. the executable called 'gcc' and 'g++' are just the compiler drivers and in turn run the seperate compiler passes depending on the languages.
12 years ago I used the Mentor Graphics system to do circuit design and analysis. 68000 unix based black & white terminals with a sun box as the server.
The GUI for designing your circuits was very interesting. It had a section for a command line. Whenever you did any action with the mouse, it typed the equivalent command line into itself and executed it.
So some people could use the mouse for some things and type the command line for other things. Whatever they wanted. Because it was ultimately command line based you could easily do scripting to express more complex or repetitive tasks. So it was the best of both worlds. It also allowed a clean design break between the gui section of the code and the algorithm section of the code - both sections were actually seperate programs.
I HATE gui's for programs that force you to do repetitive mouse actions in order to do anything more advanced than the designer imagined.
The only current apps that I can think of now that do this kind of thing are the GDB gui front ends, and I like it.
Q: I can run Linux on my Dual Mac G4, so why couldn't they make Be run on it? A: Because if they based their BeOS
development on the Linux porting work, they would be 'infected' by the 'viral' nature of the GPL and would have to open
source their OS.
My point is that the the architecture information is available. You don't have to use linux source code with its 'Viral' nature. NetBSD and Darwin are available for Mac's now with more applicable licenses.
Q: BTW anyone know of a BeOS-like GUI class library that runs on Linux so we can port our programs? A: Have you checked out
the Berlin? The only way to get anything like BeOS performance is to scrap X-windows. I don't know if Berlin is any faster
but it seems to be the only other prevalent GUI to Linux.
Last I looked at Berlin it still wasn't complete. But I am looking for a class library that is very similiarly laid out as the Be GUI class library so I can take existing BeOS app code and port it easily to either WIN32 or X.
On a semi-related note, what happened to the GUI which you could get from Kaffe 1.1 (or so). You didn't even need an X server at
all, Kaffe drew its own AWT classes. This would be great, to be able to simply boot the Linux kernel and bring up a JDesktopPane.
That WOULD be interesting. I didn't know Kaffe had GUI capabilities! Thx.
Actually, the problem was that the hardware sucked. I had one in 96! The company I work with had the most Be Boxes compared to any other company besides Metrowerks. Unfortunately, our main control software only runs on BeOS, and we are still shipping it.
The hardware sucked because even though it had dual processors, the processors and the supporting chipset did not allow for cache memory if you had dual processors. So, it ran slower than the single processor macs.
Then Be just decided to write BeOS so it runs on existing PPC Mac's. Steve Jobs stopped that when he went back to Apple and closed the mac architecture again. So Be got investment from Intel and started migrating BeOS to Intel. I SUSPECT that Be had some sort of agreement with Intel to phase out PPC support - I can run Linux on my Dual Mac G4, so why couldn't they make Be run on it?
My experience with BeOS has been long and sad. Beta versions and Release Candidate version going on for years. Every new version required ALL apps to be recompiled because of the 'C++ fragile base class' problem. It was neat to see the O/S architecture done in C++ but I think it caused way too much trouble in the long run. Plus they wrote the C++ code before the ANSI C++ standard was finished, so now there are much better ways of implementing the same kinds of things. BeOS serial drivers were broken for a long time, sometimes sending bytes OUT OF ORDER!
My current BeOS installation kernel panics now when I move my mouse IF a single byte has been received by my real Roland MPU-401 MIDI interface (i.e. not defaulting to UART mode). Networking plain sucks without BONE, but BONE hasn't been released. Without BONE a 100bT connection is lucky to run at 5 megabits per second!
GUI design is painful with no standard gui designer or resource editor. Hell even my old Atari ST in 1986 was easier to design GUI's with! There were GUI design programs but most if not all were closed source and therefore useless when the next version of BeOS came out until the small-time author decided to port it. Many third party support libs were closed source and just abandoned by the author.
Forced multithreading in C++ which is a language which was NEVER designed for multithreading - of course you can do it but many pitfalls await for programmers who are not anal about their semaphores. No proper debugger support for a long time. No real posix compliance.
select() works on sockets but not on serial port handles. Drivers so limited it becomes a surprise when it boots on a laptop - which was never officialy supported but necessary for us.
Mouse drivers which scan your serial ports for mice and HANG sometimes when you have a more complex device on a COM port sending data. Change the GUI default font size and all the applications gui's screw up.
The GEEKPORT, which really made the BeBox special was fun but not very well designed physically and would break or fall out during shipping.
Yes, BeOS booted FAST, ran very SNAPPY, but if it doesn't run on your computer and all the apps are unstable there is not much you can really do with it.
BeIA is probably quite decent as an embedded O/S. It contains better networking. BeOS for desktop will be gone soon, and I say "GOOD RIDDANCE"
BTW anyone know of a BeOS-like GUI class library that runs on Linux so we can port our programs?
Code-within HTML documenation is a good idea, and not a new one either. It is called Literate Programming. except usually the code is within TeX with a system called CWEB.
I believe your idea of sticking the code and documentation into XML is best however. Then, your code can live in a real database (instead of a CVS repository) and you could do much more powerful manipulations and queries of your code and versions. I use CVS all the time, but it is limited because it really does not know a language's structure.
It is the year 2001. Why do we still write code in plain text files?
You wouldn't use a 6502 to blink lights because it needs external ram and rom and additional logic just to run.
However, it makes total sense to use a motorola 68HC08 or a Microchip PIC chip even though they are faster processors than the 6502 - as these things will do the job with no additional support circuitry except a voltage regulator and an oscillator, and of course transistors to drive your blinkin lights. These chips are also CHEAPER than your lights too. Who cares then if they are overkill? They fit the requirements nicely!
Back on topic, this news from AMD is just a reminder that you have to be very very careful about which companies products you design into your embedded devices - unless you don't mind redesigning your products every year! Motorola and Microchip are my favourites because they have a huge investment and commitment to the embedded market. They will give you very early notice when they plan to retire a product line. And when they do, they usually have a very near replacement available and will give you deals to buy enough of the old product before it is gone so you can still sell products while you gear up for the new one.
Intel is good for this as well for their embedded products. I personally would stay away from Cyrix and AMD now.
YES! As long as it can interface well with C. The DSP algorithms usually have to be rewritten from scratch anyways!
For example in C and C++ I end up rewriting the standard biquad filter not just for each DSP architecture but for each way that the data would be organized. And the math is the same (and pretty simple) in each way. I feel that this is exactly the case where the compiler could do the re-organization for me. But the compiler needs to know a higher level concept of what I am trying to do - So it could not only run multiple iterations of a loop in parallel - it should also be able to interlace the instructions that comprise two or more function calls with each other (that are allowed to be done in parallel) in order to fill up the pipeline.
Slashdot Mirror
Very cool stuff Justin!
My question for you is: Will it work over the Internet as is now, or do all the routers in between the source and the destinations have to be specially set up to handle the multicasting traffic? I did a number of multicast experiments a couple years ago and found multicast to be unusable over the net because the routers dropped all the packets.
--jeff
In the case of a LCD cell, the required charge on the cell is very very tiny. Therefore the impulse current required is miniscule.
Once I was playing around with a bare dot matrix LCD panel - looks just like a piece of glass. I could make the cells go black by holding it on one side where the almost transparent rows of wires were and waving it in front of a computer monitor or even near someone else. The static charge was enough to make the cells dark - And stayed that way for over half an hour.
Fun stuff
--jeff
As others have pointed out, the LCD stops the transmission of light when voltage is applied, hence giving you black.
But one other nit-pick: "I don't understand why you need power to produce black" - No you don't need power. You need Voltage. The LCD cell acts like a capacitor and does not pass DC electricity though it. So no current, and hence no power used.
Leakage would probably be in the micro-amp range.
--jeff
Problem is that Win95 won't have all the driver support for the chipsets in the new computers!
--jeff
Any guess how long it will be before you will require a government license to run a webserver on the internet?
--jeff
AC, Drop the old meaning for 'Hacker'. Give it up. It's lost. It has a new meaning now - a very dark and evil one.
Why do you need to label yourself anyways?
--jeff
Don't worry - Soon paper shredding will be illegal too!
--jeff
I agree with you.
However it is not your job to test the security of someone else's system.
It is like breaking into a bank's safe in order to demonstrate the failure of their security system. Very unwise. Don't do it.
I hope though that they eventually DO have different charges and penalties for different hacking actions. Unfortunately, most law-makers are clueless with regards to technology.
My original point was just that hacking CAN be worse than murder. And it doesn't have to be a military site either - an evil hacker modifying www.cnn.com could cause huge effects.
My wish is that sysadmins who are negligent in keeping their system secure share in the responsibility of the damage that occurs when it is hacked.
If I leave my car parked with the engine running and the door opened for half an hour, I think the insurance company will blame me just as much as the thief. If an admin runs IIS and ignores the security patches, he should get blamed as well.
--jeff
Well, they aren't DIRECTLY accessible.
But it has happened indirectly where some idiot connects their insecure WinNT machine to the internal secure network. Once someone hacks the insecure machine he has access to the secure network.
--jeff
No, not an idiot. Just the devil's advocate.
--jeff
Yes, murder is less of an offense than hacking.
Hacking a military site can affect THOUSANDS of lives and national security.
--jeff
In fact, with a very good low noise cd player (which is 16 bits) and a 24 bit A/D converter you will get a result that is almost perfect - the only possible tiny glitches would be from slight differences in the sample rates.
--jeff
They've ALWAYS announced products before they were even started in order to get people to hold off buying the competitor's products. "Oh, but microsoft is coming out with a product very soon that will be better than your product". Then 'very soon' turns into delays and more delays mixed with more hype as they actually start to desgin the product. And people are still holding off buying the competitor's product. Eventually microsoft's product is finally released (with many bugs) and everyone is SO HAPPY to buy their long awaited thing. In the meantime, the competition has suffered. Sometimes the competition suffers enough to be bought up by microsoft for dirt cheap.
Ever hear about 'Microsoft for Cable TV?'
They failed at that - spent huge money on it, didn't even get a product out the door. Then they bought WebTV instead for cheap.
--jeff
That works for me!
--jeff
I think it is time to GIVE UP the hacker title. The original meaning is lost forever. Call yourself a 'Computer Programmer' instead and everyone will be happier and will not be confused anymore.
Everyone knows that Hackers are all terrorists, anyways!
--jeff
But that would be ILLEGAL with a massive jail sentence!
--jeff
#1 Only government approved crypto (with content copy protection built in as well as a back door) would be allowed over communication lines.
#2 With government being friendly to the law-breaking Microsoft, only Windows XP2 and Solaris will support this crypto.
#3 The crypto will be closed source. Therefore any GNU GPL'd O/S will be illegal.
#4 The system will be quickly and silently hacked and Bin Laden and his terrorist friends can wreak havoc on our economy and people AGAIN with a simple telephone call.
Just because a law is stupid and ineffectual does not mean it won't happen.
--jeff
Read up on the US Constitution. The constitution has nothing to do with restrictions of corporations, only restrictions of government.
--jeff
GCC does NOT contain all languages in one binary. the executable called 'gcc' and 'g++' are just the compiler drivers and in turn run the seperate compiler passes depending on the languages.
12 years ago I used the Mentor Graphics system to do circuit design and analysis. 68000 unix based black & white terminals with a sun box as the server.
The GUI for designing your circuits was very interesting. It had a section for a command line. Whenever you did any action with the mouse, it typed the equivalent command line into itself and executed it.
So some people could use the mouse for some things and type the command line for other things. Whatever they wanted. Because it was ultimately command line based you could easily do scripting to express more complex or repetitive tasks. So it was the best of both worlds. It also allowed a clean design break between the gui section of the code and the algorithm section of the code - both sections were actually seperate programs.
I HATE gui's for programs that force you to do repetitive mouse actions in order to do anything more advanced than the designer imagined.
The only current apps that I can think of now that do this kind of thing are the GDB gui front ends, and I like it.
--jeff
Q: I can run Linux on my Dual Mac G4, so why couldn't they make Be run on it? A: Because if they based their BeOS development on the Linux porting work, they would be 'infected' by the 'viral' nature of the GPL and would have to open source their OS.
My point is that the the architecture information is available. You don't have to use linux source code with its 'Viral' nature. NetBSD and Darwin are available for Mac's now with more applicable licenses.
Q: BTW anyone know of a BeOS-like GUI class library that runs on Linux so we can port our programs? A: Have you checked out the Berlin? The only way to get anything like BeOS performance is to scrap X-windows. I don't know if Berlin is any faster but it seems to be the only other prevalent GUI to Linux.
Last I looked at Berlin it still wasn't complete. But I am looking for a class library that is very similiarly laid out as the Be GUI class library so I can take existing BeOS app code and port it easily to either WIN32 or X.
On a semi-related note, what happened to the GUI which you could get from Kaffe 1.1 (or so). You didn't even need an X server at all, Kaffe drew its own AWT classes. This would be great, to be able to simply boot the Linux kernel and bring up a JDesktopPane.
That WOULD be interesting. I didn't know Kaffe had GUI capabilities! Thx.
--jeff
Actually, the problem was that the hardware sucked. I had one in 96! The company I work with had the most Be Boxes compared to any other company besides Metrowerks. Unfortunately, our main control software only runs on BeOS, and we are still shipping it.
The hardware sucked because even though it had dual processors, the processors and the supporting chipset did not allow for cache memory if you had dual processors. So, it ran slower than the single processor macs.
Then Be just decided to write BeOS so it runs on existing PPC Mac's. Steve Jobs stopped that when he went back to Apple and closed the mac architecture again. So Be got investment from Intel and started migrating BeOS to Intel. I SUSPECT that Be had some sort of agreement with Intel to phase out PPC support - I can run Linux on my Dual Mac G4, so why couldn't they make Be run on it?
My experience with BeOS has been long and sad. Beta versions and Release Candidate version going on for years. Every new version required ALL apps to be recompiled because of the 'C++ fragile base class' problem. It was neat to see the O/S architecture done in C++ but I think it caused way too much trouble in the long run. Plus they wrote the C++ code before the ANSI C++ standard was finished, so now there are much better ways of implementing the same kinds of things. BeOS serial drivers were broken for a long time, sometimes sending bytes OUT OF ORDER!
My current BeOS installation kernel panics now when I move my mouse IF a single byte has been received by my real Roland MPU-401 MIDI interface (i.e. not defaulting to UART mode). Networking plain sucks without BONE, but BONE hasn't been released. Without BONE a 100bT connection is lucky to run at 5 megabits per second!
GUI design is painful with no standard gui designer or resource editor. Hell even my old Atari ST in 1986 was easier to design GUI's with! There were GUI design programs but most if not all were closed source and therefore useless when the next version of BeOS came out until the small-time author decided to port it. Many third party support libs were closed source and just abandoned by the author.
Forced multithreading in C++ which is a language which was NEVER designed for multithreading - of course you can do it but many pitfalls await for programmers who are not anal about their semaphores. No proper debugger support for a long time. No real posix compliance.
select() works on sockets but not on serial port handles. Drivers so limited it becomes a surprise when it boots on a laptop - which was never officialy supported but necessary for us.
Mouse drivers which scan your serial ports for mice and HANG sometimes when you have a more complex device on a COM port sending data. Change the GUI default font size and all the applications gui's screw up.
The GEEKPORT, which really made the BeBox special was fun but not very well designed physically and would break or fall out during shipping.
Yes, BeOS booted FAST, ran very SNAPPY, but if it doesn't run on your computer and all the apps are unstable there is not much you can really do with it.
BeIA is probably quite decent as an embedded O/S. It contains better networking. BeOS for desktop will be gone soon, and I say "GOOD RIDDANCE"
BTW anyone know of a BeOS-like GUI class library that runs on Linux so we can port our programs?
--jeff
Code-within HTML documenation is a good idea, and not a new one either. It is called Literate Programming. except usually the code is within TeX with a system called CWEB.
I believe your idea of sticking the code and documentation into XML is best however. Then, your code can live in a real database (instead of a CVS repository) and you could do much more powerful manipulations and queries of your code and versions. I use CVS all the time, but it is limited because it really does not know a language's structure.
It is the year 2001. Why do we still write code in plain text files?
You wouldn't use a 6502 to blink lights because it needs external ram and rom and additional logic just to run.
However, it makes total sense to use a motorola 68HC08 or a Microchip PIC chip even though they are faster processors than the 6502 - as these things will do the job with no additional support circuitry except a voltage regulator and an oscillator, and of course transistors to drive your blinkin lights. These chips are also CHEAPER than your lights too. Who cares then if they are overkill? They fit the requirements nicely!
Back on topic, this news from AMD is just a reminder that you have to be very very careful about which companies products you design into your embedded devices - unless you don't mind redesigning your products every year! Motorola and Microchip are my favourites because they have a huge investment and commitment to the embedded market. They will give you very early notice when they plan to retire a product line. And when they do, they usually have a very near replacement available and will give you deals to buy enough of the old product before it is gone so you can still sell products while you gear up for the new one.
Intel is good for this as well for their embedded products. I personally would stay away from Cyrix and AMD now.
--jeff
YES! As long as it can interface well with C. The DSP algorithms usually have to be rewritten from scratch anyways!
For example in C and C++ I end up rewriting the standard biquad filter not just for each DSP architecture but for each way that the data would be organized. And the math is the same (and pretty simple) in each way. I feel that this is exactly the case where the compiler could do the re-organization for me. But the compiler needs to know a higher level concept of what I am trying to do - So it could not only run multiple iterations of a loop in parallel - it should also be able to interlace the instructions that comprise two or more function calls with each other (that are allowed to be done in parallel) in order to fill up the pipeline.
--jeff