Yet no one complains that their button presses are too slow.
Firefox's GUI is incredibly slow in places. For instance, if I invoke the File/Save dialog, there's a perceptible pause before a gray, empty dialog box appears; then another pause before it's painted.
After I click "save", the button depresses and stays depressed for almost a second. Then the dialog box goes back to plain gray, and lingers for several seconds before disappearing. This is absolutely ridiculous. I have no idea if it's javascript-related.
ASCII-based formats solve the issue of data transmission between two unknown sources...
Indeed. XML is great at bridging gaps. Programmers with very different languages, platforms and viewpoints can exchange it. However, I've become increasingly aware of the space and time hit. Which depends, of course, on the app.
Actually, as long as the sender and receiver are in C, XML has not been the bottleneck for me yet. I do have one Perl XML sender (using XML::Simple) which is a bottleneck.
One way to solve the endianness problem is with the functions in byteorder(3). Another is to prefix a sentinel word and have the receiver swab(3) as needed if the word is reversed. That makes a lot of sense if 99% of boxes are x86.
Durability is a requirement for some applications; a luxury in others, and completely irrelevant in a third group.
Durability comes with a steep price - syncing to disk after every atomic unit of data. This defeats the OS's carefully designed buffering. Most applications do not guarrantee durability. When you type a character into Microsoft Word, it is not synced to disk. When you make a TCP/IP connection, the kernel stores the connection state in RAM and never writes it to disk.
Just because an application uses a database for storage does not mean it wants guarrantted durability.
I'm getting a little tired of seeing that "benchmark" posted. I am not some kind of blind perl-worshipper - I mostly program C++ these days. But I have to point out that the programs in this benchmark are far from the domain where Perl is commonly used. Calculating digits of PI? If you actually need to do that, use C. Trees? Not a common structure in Perl programming. The language has a built-in associative structure (hash).
The class of problems for which Perl was created is a bit more complex than integer math. The point of both Java and Perl is to manage complexity at the cost of some performance loss. In a typical Perl program, much of the CPU time is spent in the hash implementation and the regex engine. Both of these are written in C and well optimized.
Want a more real-world comparison? Check out the phonecode paper of Lutz Prechelt. (Warning - pdf).
Prechelt's data agree with my experience. Java applications are, on average, slow. Perhaps this is due to mistakes in coding or deployment. Either way, the "benchmark" on debian is self-serving nonsense.
I support the right to bear arms, but I think you're a bit too optimistic:
Just showing a potential attacker that you are carying on your belt is enough to make him melt away.
That might apply to some attackers, but the serial mugger/rapist will often ambush his victim in such a way that there's no time to react. Which means you lose an expensive firearm along with your wallet and cell phone.
However, if enough of the populace is armed and has the right attitude, we could reach a point where muggers/rapists risk being shot by witnesses.
It pisses me off that "offensive" is used as a blanket term of condemnation. Any serious idea can offend someone. The fact that a comment is deemed "offensive" is irrelevant to the truth of the comment.
plain vi - mode and backspace
on
The Birth of vi
·
· Score: 1
The lack of mode notification sucks.
The backspace problem is probably with your terminal config. You can fix it with stty. Once you get the formula, put it in your.profile or something.
Something like: stty erase ^Vbackspace.
Alternatively, vi doesn't understand your terminal type. echo $TERM. Try "export TERM=vt100" or something.
Others are pointing out that vi works over modems, is available on all servers, etc. But if that were the only motivator, I could use vi in those situations and something more "modern" for development.
I've used Eclipse and Visual Studio. In both cases I tried to get over the initial revulsion and find out what's attractive about these tools. In both cases I went back to vi in a month or two.
I find that GUIs break my concentration. Vi lets me focus on the code - the task of communicating with the machine is in muscle memory.
Most people today, including most computer people, don't seem to share your belief that it's evil to place your hand on the mouse...
I've worked with programmers of varying abilities over the years. All the really good ones use vi or emacs. Most programmers shouldn't be programmers. They lack the abstract thinking needed to create substantial value in software; they are merely clerks copying data from A to B.
Don't expect good programmers to follow the lead of bad programmers, let alone "most computer people". Would you expect automotive engineers to stop using ProE because car mechanics don't use it?
Except that environmentalists interests are for the general welfare of the planet and its inhabitants...
Absolutely not. Aside from the fact that such a broad agenda would be completely meaningless (who are they against, extraterrestrials?), environmentalism is concerned with the earth, defined as everything except humans. In fact, environmentalists have wished for the destruction of humankind, so that the earth could heal from the wounds humans inflicted and return to a natural state.
...those children who drink the most milk gain the most weight...
And Philip Coan replies:
A US study looked at milk consumption in two to five-year-olds over a three-year period. It found no link between increases in child weight and increases in drink consumption.
The celebrity claimed a relationship between increases in weight and level of milk consumption.
In relation to milk, child weight was not linked to whether the children drank full-fat, semi-skimmed or skimmed milk.
Nor did the celebrity claim such a linkage. Milk has about 14 grams of sugar per cup, regardless of its fat content. Eating lots of sugar can certainly lead to obesity.
Lastly, the celeb made a statement about children, and Coan rebutted it with a study on two to five-year-olds.
I'm not saying the celeb is necessarily right, but this rebuttal is hollow.
COBOL provided a way to write business apps from scratch. But increasingly business runs on commercial, packaged software (ERP) that is customized or configured to the specific business. For example, SAP and Oracle Applications.
I think the companies that computerized early are more likely to be using home-grown software, probably written in COBOL. That is, companies like airlines, banks and power utilities.
Buying an ERP system and customizing it provides much higher leverage than writing the app from scratch in COBOL. This is because businesses have a lot in common.
The ERP systems have their own programming languages. SAP has ABAP, which is somewhat similar to COBOL. I think Oracle Applications customization can be done with PL/SQL (Oracle Forms runs it). Peoplesoft has Peopletools - though I can't tell if it's a language, an IDE, or both. This is the dark side of the moon; off the radar of academics and hackers. While the web is full of programmers discussing C, Perl, Java, etc. the business programmers seem to have less desire for public discussion.
So my guess is that COBOL was not replaced by C, Perl, etc. but by ABAP, PL/SQL, etc. I'd appreciate any knowledgeable comments, as this is a fascinating area.
I read Tanenbaum's paper when it came out. One of the soundbites:
RFID malware is a Pandora's box that has been gathering dust in the corner of our 'smart' warehouses and home.
This is not true. There is no Pandora's box. Read the paper and you'll see why.
Tanenbaum and his co-authors exploited vulnerabilities in RFID middleware - the software that connects to an RFID reader. What makes this less interesting is that they wrote the middleware. Yes, they deliberately built in vulnerabilities like SQL injection, then crafted RFID tags to exploit them.
Tanenbaum's team did not find any weaknesses in any commercial RFID middleware. And their entire premise is flawed. The weaknesses they scanned for, such as SQL injection, are not going to exist in the dominant RFID system, which is EPC. An EPC tag contains a binary number (frequently 96 bits). This bit vector is divided into fields for manufacturer, part number, and serial number. It is binary, not text. There is no way a malformed number could trigger an SQL injection vulnerability.
I got my info from a book by a KGB defector - can't remember his name. He worked on COMSEC for Russia. Didn't provide any technical details (voltages, frequencies, etc.). But the book has lots of interesting stories. An eastern-block agency was spying on a Russian agency with this method. They parked a car underneath the building's overhead power line, and extended a thin wooden pole that nearly touched the power line. Also, when the US opened a new embassy in Moscow, the joke was that the flowers would always wilt immediately (due to massive RF power levels). Soviet cipher clerks in embassies around the world frequently got leukemia, because they spent hours in a small metal box with an RF jammer as powerful as a TV station.
Searching for 'rf flooding' or 'frequency flooding' gets some related hits, but nothing good.
I don't really see how that's possible. When the handset is on-hook, the microphone is disconnected. This is a requirement for BABT compliance.
Unless you disassemble and inspect the phone every time you enter the space, you have no idea what's inside. (And even then, if your adversary has sufficient resources). There are lots of ways to modify a phone for remote monitoring - search for "hook switch bypass". In this scenario, if the officers executed a search warrant earlier, they could have modified or substituted the phone.
Since at least the 70s, intelligence agencies have been eavesdropping via light bulbs, flourescent light ballasts, phones, and other electrical equipment. The eavesdropper sends a high-powered RF carrier down the wire, and the equipment modulates the carrier in response to voice pressure. I haven't heard of this technology being used by law enforcement.
As a kid, I was interested in pro audio. Later I would end up working about 9 years in the industry. I had built several speakers, but they were unimpressive since I couldn't afford good components.
In the 80's the CD horn (constant directivity) was gaining acceptance. Old PA speakers used exponential or radial horns for their mid-hi output. These horns, like the tweeter on a consumer speaker, produce a "brighter" sound on-axis than off-axis. That is, they cover a wider angle at lower frequencies, and gradually narrow at higher frequencies. (In the case of radials, this is only true vertically).
This behavior is bad in both home and PA speakers. For PA's, it defeats the goal of delivering a uniform experience to each guest.
Some papers in the Journal of the Audio Engineering Society showed how to design a CD horn which solves this problem. I spent a lot of time analyzing the commercial horns; many were compromise attempts at CD, because CD horns are big. By measuring photos, I could extract the geometry.
First Attempt
I designed my own horn. It would be taller than most comparable commercial units used in cabinets - about 12" wide by 9" high. I made a male mold by slicing the design into layers 3/4" thick and cutting them from plywood. Then I plastered the stairstep into a smooth surface, sanded and varnished it till it was glossy. I bought polyester resin, fiberglas cloth and roving. Applied plenty of mold release to the male mold, and laid up the horn.
When the resin had cured, I found it was impossible to extract the male mold from the horn. I now had a large, heavy, completely useless amalgam of wood and fibreglas.
Second Attempt
I had built the male mold ruggedly, hoping to make multiple horns with it. Starting over, a I built a flimsy hollow male mold of masonite, with plaster providing the radiuses transitions. Again, I sanded and varnished. I made the trickiest part out of wax, casting it in a special mold. Since this part was so hard to dislodge, I planned to melt it out of the final horn.
This time it worked. I destroyed the masonite mold pulling it out. I heated and ejected the wax portion. I bolted on a JBL 2426 compression driver - a fairly nice 1" exit driver. I had built an electronic crossover, but couldn't get it to work - the opamps would float up to the v+ rail. So I used a graphic EQ as a XO and paired the horn with a previously built cabinet for bass - crossed them at 1600 and dialed in the "mass corner" eq. CD horns need an eq boost above their "mass corner", around 3.5k where the mass of the diaphragm creates a low-pass filter.
Results
The driver/horn combo sounded awesome. Really clear, airy highs; sharp attack on percussion, and none of the "honk" you hear in cheap PA speakers. My fiberglas work was horrible; very heavy and fully of air bubbles, with a rough backside.
Sounds awfully familiar. What would be even better is if our hero realizes at the last minute that the agency is not trying to wipe out humanity; it's just a BS rumor started by some guy on the internet. So he tracks the guy down and gives him 20 lashes with his own mouse cord.
After Microsoft's emails emerged in their trial, a lot of companies started emphasizing document retention policies. Meaning, of course, document destruction policies. These can probably minimize the embarassing electronic documents, but what about paper?
To take an example nearer the geek's heart, look at IBM producing documents for SCO. I think SCO demanded not only every electronic version of source code, but every printout.
CEOs would probably be very happy to know that all paper in their company is the fading kind, so document retention is purely an electronic issue.
Slashdot Mirror
Firefox's GUI is incredibly slow in places. For instance, if I invoke the File/Save dialog, there's a perceptible pause before a gray, empty dialog box appears; then another pause before it's painted.
After I click "save", the button depresses and stays depressed for almost a second. Then the dialog box goes back to plain gray, and lingers for several seconds before disappearing. This is absolutely ridiculous. I have no idea if it's javascript-related.
You did not restrict that claim to production code.
How does the obviousness of production code differ between C and Perl?
Really? Care to apply that concept to this or this?
Well, Sunni Islam is based on the Koran and Hadiths (arabic plural=ahadith). They are reports of the actions and speech of Mohammed.
Wikipedia says:
Phones typically run J2ME - Java 2 Mobile Edition. It is much smaller than J2SE or J2EE. S=standard, E=enterprise.
Actually, as long as the sender and receiver are in C, XML has not been the bottleneck for me yet. I do have one Perl XML sender (using XML::Simple) which is a bottleneck.
One way to solve the endianness problem is with the functions in byteorder(3). Another is to prefix a sentinel word and have the receiver swab(3) as needed if the word is reversed. That makes a lot of sense if 99% of boxes are x86.
Not everyone using a "database" needs durability.
Durability is a requirement for some applications; a luxury in others, and completely irrelevant in a third group.
Durability comes with a steep price - syncing to disk after every atomic unit of data. This defeats the OS's carefully designed buffering. Most applications do not guarrantee durability. When you type a character into Microsoft Word, it is not synced to disk. When you make a TCP/IP connection, the kernel stores the connection state in RAM and never writes it to disk.
Just because an application uses a database for storage does not mean it wants guarrantted durability.
I'm getting a little tired of seeing that "benchmark" posted. I am not some kind of blind perl-worshipper - I mostly program C++ these days. But I have to point out that the programs in this benchmark are far from the domain where Perl is commonly used. Calculating digits of PI? If you actually need to do that, use C. Trees? Not a common structure in Perl programming. The language has a built-in associative structure (hash).
The class of problems for which Perl was created is a bit more complex than integer math. The point of both Java and Perl is to manage complexity at the cost of some performance loss. In a typical Perl program, much of the CPU time is spent in the hash implementation and the regex engine. Both of these are written in C and well optimized.
Want a more real-world comparison? Check out the phonecode paper of Lutz Prechelt. (Warning - pdf).
Prechelt's data agree with my experience. Java applications are, on average, slow. Perhaps this is due to mistakes in coding or deployment. Either way, the "benchmark" on debian is self-serving nonsense.
That might apply to some attackers, but the serial mugger/rapist will often ambush his victim in such a way that there's no time to react. Which means you lose an expensive firearm along with your wallet and cell phone.
However, if enough of the populace is armed and has the right attitude, we could reach a point where muggers/rapists risk being shot by witnesses.
It's also only 2 chars, or 3 keystrokes as opposed to 9. Makes sense to abbreviate such a commonly used noun here.
Also, since M$ made their name as a BASIC vendor, it seems appropriate to use a BASIC-style variable.
And mods, the parent did not deserve a 'flamebait' mod. Save that for posts that are just hurling feces at the monitor.
It pisses me off that "offensive" is used as a blanket term of condemnation. Any serious idea can offend someone. The fact that a comment is deemed "offensive" is irrelevant to the truth of the comment.
The lack of mode notification sucks.
.profile or something.
The backspace problem is probably with your terminal config. You can fix it with
stty. Once you get the formula, put it in your
Something like: stty erase ^Vbackspace.
Alternatively, vi doesn't understand your terminal type. echo $TERM. Try "export TERM=vt100" or something.
I've used Eclipse and Visual Studio. In both cases I tried to get over the initial revulsion and find out what's attractive about these tools. In both cases I went back to vi in a month or two.
I find that GUIs break my concentration. Vi lets me focus on the code - the task of communicating with the machine is in muscle memory.
I've worked with programmers of varying abilities over the years. All the really good ones use vi or emacs. Most programmers shouldn't be programmers. They lack the abstract thinking needed to create substantial value in software; they are merely clerks copying data from A to B.
Don't expect good programmers to follow the lead of bad programmers, let alone "most computer people". Would you expect automotive engineers to stop using ProE because car mechanics don't use it?
Absolutely not. Aside from the fact that such a broad agenda would be completely meaningless (who are they against, extraterrestrials?), environmentalism is concerned with the earth, defined as everything except humans. In fact, environmentalists have wished for the destruction of humankind, so that the earth could heal from the wounds humans inflicted and return to a natural state.
And Philip Coan replies:
The celebrity claimed a relationship between increases in weight and level of milk consumption.
Nor did the celebrity claim such a linkage. Milk has about 14 grams of sugar per cup, regardless of its fat content. Eating lots of sugar can certainly lead to obesity.
Lastly, the celeb made a statement about children, and Coan rebutted it with a study on two to five-year-olds.
I'm not saying the celeb is necessarily right, but this rebuttal is hollow.
Ego - that's the other motivation. Telling the traitor that his insights are appreciated at the highest levels.
What makes you think Cornell doesn't realize that? Did you think the quoted statement called C# a dynamic language? It didn't.
COBOL provided a way to write business apps from scratch. But increasingly business runs on commercial, packaged software (ERP) that is customized or configured to the specific business. For example, SAP and Oracle Applications.
I think the companies that computerized early are more likely to be using home-grown software, probably written in COBOL. That is, companies like airlines, banks and power utilities.
Buying an ERP system and customizing it provides much higher leverage than writing the app from scratch in COBOL. This is because businesses have a lot in common.
The ERP systems have their own programming languages. SAP has ABAP, which is somewhat similar to COBOL. I think Oracle Applications customization can be done with PL/SQL (Oracle Forms runs it). Peoplesoft has Peopletools - though I can't tell if it's a language, an IDE, or both.
This is the dark side of the moon; off the radar of academics and hackers. While the web is full of programmers discussing C, Perl, Java, etc. the business programmers seem to have less desire for public discussion.
So my guess is that COBOL was not replaced by C, Perl, etc. but by ABAP, PL/SQL, etc. I'd appreciate any knowledgeable comments, as this is a fascinating area.
This is not true. There is no Pandora's box. Read the paper and you'll see why.
Tanenbaum and his co-authors exploited vulnerabilities in RFID middleware - the software that connects to an RFID reader. What makes this less interesting is that they wrote the middleware. Yes, they deliberately built in vulnerabilities like SQL injection, then crafted RFID tags to exploit them.
Tanenbaum's team did not find any weaknesses in any commercial RFID middleware. And their entire premise is flawed. The weaknesses they scanned for, such as SQL injection, are not going to exist in the dominant RFID system, which is EPC. An EPC tag contains a binary number (frequently 96 bits). This bit vector is divided into fields for manufacturer, part number, and serial number. It is binary, not text. There is no way a malformed number could trigger an SQL injection vulnerability.
I got my info from a book by a KGB defector - can't remember his name. He worked on COMSEC for Russia. Didn't provide any technical details (voltages, frequencies, etc.). But the book has lots of interesting stories.
An eastern-block agency was spying on a Russian agency with this method. They parked a car underneath the building's overhead power line, and extended a thin wooden pole that nearly touched the power line.
Also, when the US opened a new embassy in Moscow, the joke was that the flowers would always wilt immediately (due to massive RF power levels).
Soviet cipher clerks in embassies around the world frequently got leukemia, because they spent hours in a small metal box with an RF jammer as powerful as a TV station.
Searching for 'rf flooding' or 'frequency flooding' gets some related hits, but nothing good.
Sorry I don't have anything more concrete.
As a kid, I was interested in pro audio. Later I would end up working about 9 years in the industry. I had built several speakers, but they were unimpressive since I couldn't afford good components.
In the 80's the CD horn (constant directivity) was gaining acceptance. Old PA speakers used exponential or radial horns for their mid-hi output. These horns, like the tweeter on a consumer speaker, produce a "brighter" sound on-axis than off-axis. That is, they cover a wider angle at lower frequencies, and gradually narrow at higher frequencies. (In the case of radials, this is only true vertically).
This behavior is bad in both home and PA speakers. For PA's, it defeats the goal of delivering a uniform experience to each guest.
Some papers in the Journal of the Audio Engineering Society showed how to design a CD horn which solves this problem. I spent a lot of time analyzing the commercial horns; many were compromise attempts at CD, because CD horns are big. By measuring photos, I could extract the geometry.
First Attempt
I designed my own horn. It would be taller than most comparable commercial units used in cabinets - about 12" wide by 9" high. I made a male mold by slicing the design into layers 3/4" thick and cutting them from plywood. Then I plastered the stairstep into a smooth surface, sanded and varnished it till it was glossy. I bought polyester resin, fiberglas cloth and roving. Applied plenty of mold release to the male mold, and laid up the horn.
When the resin had cured, I found it was impossible to extract the male mold from the horn. I now had a large, heavy, completely useless amalgam of wood and fibreglas.
Second Attempt
I had built the male mold ruggedly, hoping to make multiple horns with it. Starting over, a I built a flimsy hollow male mold of masonite, with plaster providing the radiuses transitions. Again, I sanded and varnished. I made the trickiest part out of wax, casting it in a special mold. Since this part was so hard to dislodge, I planned to melt it out of the final horn.
This time it worked. I destroyed the masonite mold pulling it out. I heated and ejected the wax portion. I bolted on a JBL 2426 compression driver - a fairly nice 1" exit driver. I had built an electronic crossover, but couldn't get it to work - the opamps would float up to the v+ rail. So I used a graphic EQ as a XO and paired the horn with a previously built cabinet for bass - crossed them at 1600 and dialed in the "mass corner" eq. CD horns need an eq boost above their "mass corner", around 3.5k where the mass of the diaphragm creates a low-pass filter.
Results
The driver/horn combo sounded awesome. Really clear, airy highs; sharp attack on percussion, and none of the "honk" you hear in cheap PA speakers. My fiberglas work was horrible; very heavy and fully of air bubbles, with a rough backside.
What about Oracle Mail? Claims to be a better Exchange.
Sounds awfully familiar. What would be even better is if our hero realizes at the last minute that the agency is not trying to wipe out humanity; it's just a BS rumor started by some guy on the internet. So he tracks the guy down and gives him 20 lashes with his own mouse cord.
After Microsoft's emails emerged in their trial, a lot of companies started emphasizing document retention policies. Meaning, of course, document destruction policies. These can probably minimize the embarassing electronic documents, but what about paper?
To take an example nearer the geek's heart, look at IBM producing documents for SCO. I think SCO demanded not only every electronic version of source code, but every printout.
CEOs would probably be very happy to know that all paper in their company is the fading kind, so document retention is purely an electronic issue.