A small pad of paper would also qualify... and to make it secure, just write the info using a simple cypher.
What I would like to see is a super card or meta card where all of your credit card info are entered into it and the user can select which card they want to use. No more carrying around a dozen different credit cards, store cards, etc. - one card does it all!
By the way, I'd strongly advise against losing that card!
Memory fails me at the moment, but the man who developed the whole concept of relational databases... worked at IBM as I recall, and cape up with the concept of ACID: Atomic, Consistent, Isolated, Durable. I'm hoping a fellow/.'er can come up with the name for me (a quick google came up empty.) Imagine where'd we be today without RDBs!
Having experienced the Morris Worm first-hand, I'd like to point out that it did not occur in 1998, but in 1988. (Specificall, Nov. 2, 1988) And, although the worm could only infect certain hardware/os platforms, it had the effect of knocking out many others. This was the result of a bug in the worm's code -- it would repeatedly infect vulnerable systems until so many instances were running on one box that it would bring that system down to its knees. As a side effect, its attempts to infect neighboring systems caused a major load on those systems, too. So, in some respects, it was the first [D]DoS attack, too.
I'm looking for a keyboard, too. Specifically, one that mimics the incredible feel of the keyboard that came with the IBM PS/2 Model P70. It was a 80386 running at 20MHz and came with a gas plasma display that tilted out. It was called a portable computer, and that was being generous as it had to run on A/C and weighed about 20 pounds!
The keyboard had a very light touch but never missed a key press on me. My fingers just FLEW along that keyboard! At the end of the day, I had not even a hint of fatigue from typing, either. It was the best keyboard I've ever used in 30 years of programming, and I've worked on everything from mainframes and minis to PCs. Heck, I started with a teletype which had a built-in accoustically coupled modem that we used to dial up a DEC PDP-8!
If anyone ever made a keyboard like that which I could use with my PC today, I'd buy up several in a heartbeat!
keep in mind that you average non-technical user is not going to be checking for frequent patches.
Since it's free and extraordinarily easy, why not? Most distros have single click or single commandline (often both) commands to update, with all security upgrades occuring, and offering new features.
After 30 years working with computers, and 20 years in Software QA, I can give you a very good reason why NOT to immediately apply all software updates immediately. It is virtually impossible (read that incredibly difficult and expensive) to write perfect software -- I've yet to see any personally. In my experience, it's all too painfully common for one bug fix to cause yet another bug to appear whether it's by breaking something that used to work or by revealing a previously hidden bug.
I've worked at companies that ran through a whole gamut of acceptance tests before they upgraded users' systems to a new release of anything. Their business depended on having a known platform for their users. Think of training, help desk, and the like.
I'm NOT saying users should not upgrade, only that there is a good reason for some users to not immediately install every new fix that comes down the pipe.
Ask the powers that be: How much work could you do in a day if your desk had a 21-inch diagonal?
I used 3 monitors (each attached to its own PC) at my last job. I was doing QA with much automated testing. I was testing interactive web sites as well as database migration, conversion, and update efforts. My monitors? One had a 17-inch diagonal and the other two were 21-inch, as follows:
21-inch monitor #1: Input. Here is where I would write test drivers, create input files, and in general produce the stuff that would be fed into the application under test.
21-inch monitor #2: Processing. Here is where I'd actually run my tests. I could have multiple browsers or database windows open at once and all visible at the same time. Nothing else was being done on this machine so as to keep it as much like a customer environment as possible. This is the one where I spent most of my time.
17-inch monitor #1: Output. This is where I would monitor log files while tests were executing. It was also where I'd run my bug reporting application, process e-mail, write reports, etc. I was pretty much free to do whatever I wanted on this PC without concern for it impacting what I was developing or testing.
I ran the 21-inch monitors at 1600x1200 and the 17-inch at 1280x1024. I shudder to think at how much longer it would have taken me to accomplish anything if I only had one 17-inch monitor to work with!
Was it worth it? Let me put it to you this way: The two PC's with the 21-inch monitors -- I purchased them (PCs and monitors) on my own, out of my own pocket. I have no absolutely no regrets. If anything, I'm looking forward to when I can afford to buy another 21-inch monitor so I can run with 3 of them side-by-side.
Persuasion: How do you persuade the powers-that-be to take the plunge? Ask one of them to sit at the computer for an hour as you talk them through your normal daily tasks. Have them remember the stuff that you need to remember as you switch between desktops or windows. Then, go to another PC where you've set up a dual monitor configuration (e.g. borrow the monitor for another coworker). Now talk them through the same task and let them see for themself how much easier and faster to do things without having to memorize so much stuff between actions. You can keep track of more things and less stuff falls through the cracks.
When they feel your pain, and see the benefits, you won't have to convince them, they'll be rooting for YOU! Even better, they may well be thinking of how THEY could get a dual-monitor setup! Encourage that line of thinking, help them to attain it, and you'll have a powerful ally on your side.
Historical Perspective. About 10 years ago I was working at a company that was developing a product that ran on both OS/2 and Windows. Even with my best efforts at scheduling my tasks, I spent from 30-60 minutes a day waiting for the PC to reboot into the other operating system. This was back when a 386-25 Compaq DeskPro was REALLY fast. And expensive ($3000?) so getting dual systems was really tough to justify financially. Today, spending only a few hundred for a new graphics card and monitor should be much easier!
Have the support group join forces with the QA, Documentation, and Training groups. You are all "customers" of what development produces. Thus, you have a common perspective and interest. In short: work together and share the knowledge!
This is synergy at its finest:
The Support group learns of a bug from a customer; pass it on to the QA group. They get real-world information on what is important to be tested. If the code has a defect, but no customer encounters it, is it really a bug? When looking at the whole universe of potential inputs to the code, it is a big win for QA to know how customers actually use the product. They can tailor their tests accordingly.
The QA group, while testing a new release of the product, discovers a bug in unrelated code that has already been released. They can pass that info on to the support group so they are prepared should a customer report it. Saves wasting hours trying to isolate and reproduce a bug -- already have the details. Being able to locate and isolate bugs quickly makes you look good to the customer.
The Documentation group often finds errors, too. There's an old saying: "If you really want to understand something, try explaining it to somebody else." In the course of writing the documentation, they are going to find things that others miss. Their prespectives can be helpful to QA (Hey, you might want to add this to your tests) and to Support (This feature is complicated and customers are likely to call with problems in using it.)
The Training group can cut off problems before they happen. There's usually a number of different ways to perform a task with the product. Users often take a "recipe" approach -- they just do things the way they were shown. Training can guide users into a common approach to using the product. The more consistent the customer's use of the product, the fewer permutations that Support needs to be knowledgeable on.
There's more, but I think I've made it clear that there is much in common between these groups.
There will come up a time when you have a customer who has a problem, but development is not willing to give a priority to fixing it (maybe they are already behind schedule on the next release). If you discuss the situation with these other groups it's possible that you can provide a united front that will sway development. Or, you may find a workaround of which you were previously unaware.
Lastly, I worked in the QA department at a company where these groups were viewed as a necessary evil; development was king. But, through the approaches outlined above, we were eventually recognized as an ally and were all invited to participate in the design of the next release of the product.
Re:Cool...but an old concept
on
Water Computing
·
· Score: 3, Interesting
i seem to recall something about logic gates or some sort of logic being built out of matchboxes and beans. it played tictactoe, deciding the best move by plopping out a bean of a certain colour? i can remember neither the details nor the source.
I've seen it in a book by Martin Gardner, the game was called Hexapawn. A quick search on google should turn up more details.
Interesting! In short: it's an exhaustive search of all moves from black's perspective whereby all moves are initially possible and a loss causes the last move to be removed as a choice. I found the info
here. There's more at the site including how to implement it programatically.
Here's their explanation of the matchbox version of the game:
Gardner's machine is implemented as a set of 24 matchboxes, one for each possible board position when it is Black's move. Each matchbox has pasted on it a drawing showing this board position, as well as all possible moves from that position, drawn in different colors. Inside each matchbox are several colored beads, one for each move on the top. When it is the machine's turn to move, the human operator finds the matchbox showing the current position, draws a bead at random from the matchbox, replaces it, and makes the move thus chosen. The machine learns from its losses: when it loses, the operator removes and discards the last bead drawn. This ensures that the machine will never lose in this way again.
To keep this on topic: this game could be implemented with a water computer, too. Replace the matchboxes with different colored buckets of water. Instead of removing a bead for a loss, dump out the corresponding bucket.
For a more enjoyable game, replace the buckets of water with shots of beer. =)
... but what really scares me is what the executive VP of CompUSA says: "The remote control could well become the next standard PC peripheral". Huh? Is he saying that computers are heading down the path of glorified televisions and that in the near future all that you will need to operate your computer is a remote control?
No, I don't think a remote would be "all you will need to operate your computer". There was a time when a computer did not come with a mouse, but I'd dare say it's a "standard PC peripheral today." This doesn't mean that they've now dispensed with the keyboard -- it's just another standard control that comes with the PC. So, I take his comment to mean that there would be another standard peripheral that would come with a PC. So, you'd then have: a keyboard, a mouse, AND a remote control.
There is a glaring omission of the ONE language that ALL programmers know: profanity!;^)
Frying Pan -- Fire?
on
Jobs in Japan?
·
· Score: 4, Insightful
In a nutshell, from what I can tell from over here in the USA, our economy has things good compared to what they're dealing with in Japan.
From what I've read in the Wall Street Journal for the past few years, Japan is in the midst of a long recession. Layoffs have started to be implemented. Banks' financials are shaky and their central bank has pretty much exhausted what they can do (they've got their borrowing rate down to almost zero percent -- can't stimulate the economy much more than that!) Come to think of it, I recall they're actually in a depression -- people are putting off purchases, now, because they'll be cheaper, later. So businesses are starved for income and cut prices to drum up business; lather, rinse, repeat.
I'm not saying you shouldn't go, but I most certainly would advise you to take a long, hard look before you leap.
One thing I didn't notice in your post is how knowledgeable you are with their language? There are 4 parts to learning a foreign language: reading, writing, speaking, and listening. I studied German in High School and am still able to get by with the reading and speaking, but listening was hard (different intonations and accents) as was the writing (like programminng in a language I didn't know too well.) At least German uses basically the same alphabet as English (with the addition of some umlauts -- the two little dots over vowels). Japanese -- you need to learn a whole new alphabet, let alone the vocabulary and grammar. You've got your work cut out for you. And, if you've never learned any language other than English, doubly so. It was a real struggle to learn German in high school -- it was a whole new way of thinking. It's not like I'd think of what I wanted to say in English and do a literal translation! I had to learn to THINK in German. But, having done that, it's much easier for me to learn another language. I am now in the process of teaching myself ancient Greek and it's so much easier because I've already learned how to learn a language.
In the interim, have you given some thought to going over there for a month or two of vacation? Then you'd have a chance to get a real feel for what things are like over there. You may well find "It's a nice place to visit, but I wouldn't want to live there." But, having spent some time over there, you'll have some great experience that you can leverage should you decide to come back. I can assure you, you'll not see the world in the same way again! I was fortunate to have had a job that paid me to work for a week or two in 5 different countries in Europe. It truly broadened my horizons!
It's good you are soliciting feedback and I hope you are able to garner useful information from people who have actually lived there. So, here's wishing you the best of luck in whatever you decide.
P.S. One last thing: practice using chopsticks. =)
This is not as strange as it sounds. (pun intended) I've seen precursors to this, and have actually experienced something similar about 25 years ago.
Modem speed negotiation: Here's a more recent example with which many/.'ers are familiar. I generally get the same speed over my modem, so I've grown accustomed to a certain series of boops and beeps as it is negotiating the connection. Once in a while, though, I detect a change in how sequence sounds. Sure enough, I've connected at a different speed. I'm not even trying to tell if there's a difference, it's just that I've grown so failiar with that "melody" that any deviation sticks out like a sour note.
Visual Precedent: The first computer I ever used (back in the early 1970's) was a Digital Equipment Corp. PDP-8. It had a front panel with two sets of lights to display the current value of the accumulator and, IIRC, the current program address. When running at normal speed, the lights flashed much too quickly to make out specific values or addresses, but overall patterns did exist. It had certain normal "rhythms". It was especially easy to detect when my program entered an infinite loop - the lights lit up almost solid and stayed that way!
Personal Audio Precedent: back in the late 1970's, I had a Texas Instruments programmable calculator (TI-55, IIRC). One day, I discovered that the LEDs cast out a lot of RF noise (I'd accidentally tuned my radio to the AM band instead of FM). I had a friend who also had the same model. We spent many, many hours programming those calculators to generate different "melodies".
Windows Sound Events: I discovered I could associate different sounds with different events in Windows. There's the "normal" alert, warning, windows start, etc. sounds. I added a sound for the "Open program" event and another sound for the "Close program" event. When my system is booting up, I can hear several background tasks launch and end. What had previously been a long stare at an unchanging screen suddenly became much more informative.
I see this research as an interesting step that continues along that path.
As for me, I'm much more a visual person than auditory. I'd find it much more valuable if I could "see" my program execute. Once in a while, I've messed things up with my postscript printer and the listing came out at what appeared to be 1 point sized text; at 300 DPI, that worked out to being about 5 dots high. At times it was almost possible to make out the words, but realiistically, it was too small to be legible. But it WAS sufficient to show the structure of the program, especially since I consistently use indentation. If different colors were used to denote different structural items (conditional, loop, assignment, key words, etc.) AND there was an indicator that would highlight each statement as it was executed, then I'd be able to see the actual flow of the program. I could tell what functions and subroutines were executed most often. Hmmm, this seems like such an obvious idea... does anyone know if such a tool already exists?
On another note, It would be interesting to combine visual profiling of a program with a touch screen -- I could use different gestures to debug my program! Double-tap to zoom in/out on text; single tap to set a breakpoint on entrance/exit of a subroutine, etc.
The first is not so much a specific bug that was difficult to find, as it was the general means that I was forced to use to locate bugs. (Yes, I found quite a few.) Back in the early 80's I was working at IBM in the QA group responsible for testing their VM operating system. We were tasked with taking the existing VM OS and not only were we to improve its performance on multi-processor systems, we were also to improve its reliability by doing extensive reviews and testing. I was responsible for testing the free storage allocator.
Some background: For those who may not be aware, that whole operating system was written in IBM BAL (Basic Assembler Language) using the 370 instruction set. The VM operating system created a virtual machine environment for each user - thus producing the appearance of a machine, identical in [almost] all respects to running on the bare hardware. Those few differences pertained to some optimizations in the the virtual memory management's use of PTLBs (page table look-aside buffers) among others.
So, I needed to test memory allocation on the bare hardware to make sure that it worked okay. Once that was nailed down, I had to test memory allocation when VM was running on VM. But, there was yet another set of optimizations that I needed to test when a VM was running on VM running on VM (i.e. a "3rd level" VM).
It was not possible to just issue VM commands to test the various code paths. So, each test consisted of setting hardware breakpoints at the appropriate hex offset, and single stepping through these allocations. By the time I got to testing the 3rd level VM code, I was tracing and debugging these PTLB calculations and allocations, single stepping through instructions in hexadecimal and verifying multiple levels of indirection to memory pages where those calculations were also in hex. Those were the days! Just a year or so out of college, and I had all to myself a multi-million dollar mainframe computer that could support several hundred people!
The other bug was actually a specific bug that caused much early hair loss. I was working at a place where there was a lot of new employees come on board. Along with that, new departments were being formed, people were being promoted and moving to different groups, and there was a great deal of office moves as a result. So, it soon became a problem finding somebody's office. "Gee, wasn't Mary here just last week?"
Sensing a need, I wrote up a quick REXX program (yes, this was back in the early 80's, too) which did data aquisition through forms and supported the generation of reports sorted by various categories: Name, Department, Room Number, etc. This was pretty straightforward and in a couple days I'd gotten it coded, tested, and all the data populated. As there were only a few hundred people I used a flat file (the other alternative was creating a DB2 database and disk space was very dear back then!)
Rolled it out and received much positive feedback. Except, there was one person who noticed there was an error in the ordering of room numbers. See the format was: "Floor: 1, 2, or 3"; then the "building wing: compass direction: N, S, E, or W", and lastly, "room number: 2-digit number". As this was a rapidly growing organization, managers would be allocated several empty offices in advance for the people they'd hire during the next quarter. Also, the building had just been constructed and some areas and sometimes whole wings were still not yet ready for use so there were many gaps in the data. Here is a selection of the kinds of results I saw for the room numbers, in ascending order:
1E17
1E18
2E18
1E19
1E23
...
1S17
1S18
1S19
2S03
2S05
2S15
Why are the rooms in the South wing nicely ordered, but things are really messed up for the East wing? I spent HOURS and HOURS trying to figure this one out. See if you can tell what the problem is before reading ahead.
The problem? There is a single set of comparison operators <, =, and > and they just did the right kind of comparison depending on the data type of the operands. Well, here I was thinking the data was text, but the program was making the comparisons as if these were numbers that contained an exponent part
answer:
1. sound is much slower than radio waves, so the electronics can be slower and simpler (and therefore cheaper). To "slow down" a radio signal, you'd need a large diameter ring of sensors -- something that may not fit on top of a launch tower
Thanks for the feedback! It prompted me to do some calculations and further investigation. Apparently, there are TWO different SOLLO systems:
SOLLO 1 and
SOLLO 2. (Note: There's an error in the HTML for the SOLLO2 page where a less-than-symbol can be mistaken as the start of an HTML element.) Here's the description for SOLLO 2:
The basic concept of SOLLO 2 is the estimation of the distance of a lightning strike from the difference between the time of arrival of the visible flash and the audible thunder. SOLLO 2 locates lightning strikes to within a meter radius. The single receiving station includes an electric-field sensor at the center of a horizontal circle of 1- or 2-meter radius, four microphones placed on the circle at 90-degree intervals, and a fifth microphone 1 or 2 meters above the center. A nearby lightning strike causes the electric-field sensor to put out a pulse that is used to start the timer and to trigger the digitization and recording of microphone outputs as functions of time. The differences between times of the arrival of thunder at the five microphones range up to a few milliseconds. These differences are determined with[in] 10 s, from real-time digital cross-correlation among the microphone outputs. The direction from which the thunder came (thus the direction to the lightning strike) is computed by finding the set of direction cosines of the sound-propagation vector that yields the least squares best fit to the time-of-arrival differences, given the known speed of sound.
So, to answer my own question of why not use just RF? The speed of light is approximately 900,000 times the speed of sound; let's just call it one million (10^6) to make the calculations easier. Then, the differences between times of the arrival of thunder at the five AM receivers would range up to a few nanoseconds and the differences would need to be determined within 10 picoseconds. Ouch! I'm no electrical engineer, but that looks like terahertz to me. Getting it back down to gighertz would require expanding the baseline by a factor of 1000. That implies arranging the RF receivers around the perimiter of a circle 2 km in radius. SOLLO 2 would fit in the back of a pickup truck; mine wouldn't be quite so portable. =)
I was pondering this very thing a few days ago when a lightning storm passed by. I turned on my AM radio and discovered there was quite a range of frequencies that would pick up when there was a flash of lightning. So, my thoughts were to use a number of AM radio receivers, arranged equidistant around a circle, each sending their signals to a processor located at the center of the circle.
Now, it appears that the NASA folks are using microphones to pick up the sound of the thunder. Thunder is just the noise made by the lightning. Why not pick up the RF field, itself? I would think there would be less distortion and a clearer signal. Instead of 4 microphones, use 4 AM radios. Otherwise the technology would be the same in measuring the path differences (which was so clearly explained in the parent post).
Now, I'm aware the RF signals can also experience distortion (multi-path, etc.) so I'm not claiming that AM receivers would be a panacea, but I would think that it would be more precise than anything that could be done with microphones.
The preceding is based on what I'd learned in physics classes back in college... Is there anyone here who is more versed in RF signal processing who would care to comment?
I have no expectations that a means of blocking gravity have [or will] be found. But, if it should come to pass, I have only one question:
Won't it take all the fun out of skydiving? =)
(For the humor-impaired, that was supposed to be a joke.)
Re:programming zone?
on
Gaming Zone?
·
· Score: 4, Interesting
Does anyone here ever *think* they achieve this Flow State while coding?
Most definitely... often 2 or 3 times in a day. Never before thought to associate it with meditation, but I can see similarities.
My own experience has been that when I am in the zone, there's a certain balance:
I know [most of] the subject matter. There's only so much "new stuff" that I can squeeze into my head in a given period of time. There's a discomfort for me as I approach that limit (think cramming for final exams). The less knew stuff I have to learn along the way, the more room I have available in my short-term memory to keep track of the programming details.
There's the right amoung of challenge. There's enough of a challenge so that I'm not bored, yet not so much that I'm overwhelmed. At either of those extremes, there's a feeling of discomfort.
I'm making steady progress. When trying to develop a piece of code, there's a whole slew of decisions that need to be made each second. Variable names, language constructs (syntax), algorithms, interfaces, exception handling, etc. When I try something, and keep getting compiler errors, that'll zap me out of the zone pretty quickly. There's an element of risk-taking and success, time-after-time. Confidence builds. Anxieties fade and ultimately disappear.
I'm free from interruptions and distractions.. One phone call or someone popping their head into my office for a "quick question" can blow it all away. It's KNOWING that I won't be interrupted that allows me to put my "guard" down and apply a bit more of my mind into it. I can stay focused.
I'm physically comfortable. Not too hot or too cold. Not hungry. Helps to not be sick, too. When any of those are operative, it's a distraction from my concentration. The less intrusion from the "outside (physical) world" the better for me to focus on my "intellectual world".
I want to do it! There's a hunger, a wanting, a desire... an openness and receptivity. There's a sense of hope and joy and happiness. When I feel FORCED to do something, there's generally a displeasure, resentment, anger, and probably some fear, too.
By no means is this an exhaustive list; it's just my own experience. Yet, I suspect many of these factors are true for others. Through it all is a sense that things are within my "comfort zone"; neither too much nor too little. There's also a sense of continuity whereby each small success builds on the next until there's a sense that the next challenge can be readily solved, too. When that happens, I have no sense of the passing of time, I can see the minute details along with the big picture and all the levels in between.
In short, I'm receptive to what's coming in, I'm experiencing pleasure in what I'm doing, and I'm successful in what I'm producing.
Why does anyone need this? Even my grandmother, who is not very good with computers, can remember the sites that she likes to check every day. She can click the little "Bookmarks" menu, or even *gasp* type in a URL. So, if even the simplest computer user can get through their daily web routine without a "metabrowser", what's the point?
I'll agree that for most users at home, this doesn't seem to make much sense at first. But, there are a couple of cases in which this could be helpful.
Better Signal/Noise Ratio There's ever more data available to us. How do I find the stuff I want among all the stuff there is? Sure, there's google for looking up archived data. But, what I'd like is something that would scan the web and present only current news in my areas of interest. As elsewhere posted in this thread, to a large extent I've found that/. accomplishes this for me with respect to science and technology. I've not found something comparable for other areas in which I'm interested, especially in my town and surrounding area. Sure, there's the local newspaper, but there's that S/N ratio again! There's value in having a single site which does the sifting for me and presents only the news in which I'm interested.
The devil is in the details, though. Just how well does such a service work? They need to make a good first impression. Don't keep showing me stuff I'm not interested in, but also don't keep missing out on things I AM interested in! If there were a simple way to do it with technology, then there'd be no need for the editors on/. to sift through article submissions.
Accessibility It's one thing to bring up my browser's bookmarks at home. But what if I am away from home? When I go to my local public library or an internet cafe, they don't have my bookmarks available. Sure, I could just create my own homepage which contains my favorite bookmarks, but I know how to write HTML; and I'd wager the majority of people who browse the web do not.
It could be argued that I should just get a lap top or a PDA with a wireless connection. Yes, that would be nice, but that's not a viable option for me at the moment, economically. Maybe in a few years when the upfront and ongoing costs of a wireless PDA has come down some more. My ISP provides unlimited dial-up access for my home PC at $20 per month. We're nowhere near that for mobile access and it's just out of most people's price range.
Business executives. They have the financial means and the need for information. But, at the moment, they've got secretaries and underlings who do the sifting for them already. Add on the resistance to change from what "works" and it will take a while for it to catch on.
So, though I see some value to the concept, I don't see much of a market for it, now. But, over time as the costs go down and the capabilities improve, I can see this becoming increasingly useful.
I've also got an older Compaq Presario 1675 that has
1) broken/cracked usb port
2) cracked lid near hinges
3) 1 Hour battery life (I know, I need a new one)
Here Here! I've got an almost 5-year-old Compaq Presario 1610 that has been through the wringer and just keeps running. It survived a dozen flights, hundreds of rides on the floor of my car during my 25 mile commute to work. As I also generally carry a backback, the normal approach for me was to toss the laptop carrying case over my shoulder, and then throw the backback over the same shoulder with all its weight pressing upon the laptop. Took it like a trooper and it Just Keeps Working.
Unfortunately, it's a 150 MHz Pentium MMX; its RAM is maxed out at 80 MB, and the 1.6 GB hard drive runs 90+ percent full. So, I've been looking around for a more capable laptopn. I'd been eyeing the Dell Inspirons, but from what I've seen here... I'm definitely reappraising that idea. I've seen a couple suggestions for IBM laptops; does anyone else have a recommendation?
Though it was years and years ago, I'd done some 6502 assembler programming. In fact, I just pulled out my copy of "Programming the 6502" by Rodnay Zaks (Sybex Inc.). I was never that good at it, but I had a lot of fun trying!
Unfortunately, when I tried to download the binary ROM image of the 6502 code on his web page I got an error: Cannot find the file specified.
If/when that gets fixed, the next step would be to get a computer do the work. A quick check of google using the search string: "6502 disassembler" brought up about 337 matches. Granted, some of the disassemblers are designed to run on older hardware (e.g. Atari, Commodore 64), but I saw links for unix, windows, and DOS, too.
Pong? Nope. Star Raiders? YES!
on
Gaming on the IMAX
·
· Score: 3, Interesting
Screw Halo! Imagine playing PONG on this thing
You may laugh, but that sure brought back a memory. Back in 1981 I was in college and working at the student union setting up for a concert later that evening when one of the building's directors wheels in this big, bulky thing and starts to roll down the 20-foot diagonal movie screen. Come to find out it was a new projection TV system. (Films were popular on campus, so the thinking was why not project videos, too?)
A lightbulb went off and I asked "What does it use for inputs?"
"Basically any NTSC source; there's antenna connections and RCA jacks."
Within 15 minutes' time, I'd hooked up my Atari 800 (*) to the projector and to the concert sound system (1000 Watts!) and started Star Raiders(**). The explosions were deafening, and when I launched into hyperspace, it sounded like a jet was taking off in the student union! Got to play for almost an hour until some students complained they couldn't study.
(*) That was a 6502 (8-bit) system. IIRC it ran at 2 MHz; had 8 KB of memory; display was in color and capable of 12 rows of 40 characters. It was pretty advanced at the time!
(**) Star Raiders was a killer app of the time. Many people bought an Atari 800 (or 400) just so they could play it! It was certainly a big factor in my decision.
The developers of the hardware usually aren't the ones who are lying.
Agreed! I've seen that happen more than a few times. Thought it might be useful to add another possible reason why some features are hidden.
My expertise is with software (20+ years in QA), not hardware, but I've seen the hiding of features happen several times. In my experience, the develpment cycle starts off with marketing making its pitch for what needs to be in the product release, and development pushes back with what is feasible in the time frame, as well as what they would like to do. There's some negotiation, and then development goes off to "do their thing". And all is happy and good.
Then QA appears and does its thing. Sometimes QA is called in right from the start; other times the product is almost ready for release and someone thinks it might be good to have QA look at it before it is shipped tomorrow. I actually have seen a few projects released on time, under budget, and with the promised capabilities. But, that is sadly the exception rather than the rule. Even with an early participation by QA, there are often far more developers at work than QA people. The number of possibilities goes up exponentially, and there's just not enough time to test everything as it is developed. Design errors and implementation errors are found. Rework is required. Deadlines loom. All is not as happy and good as it once seemed. And then it happens.
Maybe it's a nasty memory leak that builds up over time. Maybe there's a variable that gets corrupted, eventually. And there's not enough time to isolate it and fix it. So, instead of yanking out all the questionable code (which would introduce its own bevy of problems), the common approach is to just remove access to it (e.g. removing a choice from a pull-down menu) and, of course, removing all reference to it in the documentation.
So, there's quite possibly some hidden functionality in a program (or a piece of hardware), but it was hidden for a reason. If you're a bleeding-edge kind of person, go have fun. In light of your particular circumstances, it might well seem to work okay. But, if you need to be able to rely on the application or system, it might be a Really Good Idea(TM) to use only the documented features. You might miss out on some helpful features, but you might also save your butt.
Slashdot Mirror
What I would like to see is a super card or meta card where all of your credit card info are entered into it and the user can select which card they want to use. No more carrying around a dozen different credit cards, store cards, etc. - one card does it all!
By the way, I'd strongly advise against losing that card!
Memory fails me at the moment, but the man who developed the whole concept of relational databases... worked at IBM as I recall, and cape up with the concept of ACID: Atomic, Consistent, Isolated, Durable. I'm hoping a fellow /.'er can come up with the name for me (a quick google came up empty.) Imagine where'd we be today without RDBs!
Check out NASA's Space Interferometry Mission site, especially their page on Planet Detection
There's much more information on that site that should sate your curiousity. HTH!
See: http://www.wikipedia.org/wiki/Morris+Worm
I'm looking for a keyboard, too. Specifically, one that mimics the incredible feel of the keyboard that came with the IBM PS/2 Model P70. It was a 80386 running at 20MHz and came with a gas plasma display that tilted out. It was called a portable computer, and that was being generous as it had to run on A/C and weighed about 20 pounds!
The keyboard had a very light touch but never missed a key press on me. My fingers just FLEW along that keyboard! At the end of the day, I had not even a hint of fatigue from typing, either. It was the best keyboard I've ever used in 30 years of programming, and I've worked on everything from mainframes and minis to PCs. Heck, I started with a teletype which had a built-in accoustically coupled modem that we used to dial up a DEC PDP-8!
If anyone ever made a keyboard like that which I could use with my PC today, I'd buy up several in a heartbeat!
After 30 years working with computers, and 20 years in Software QA, I can give you a very good reason why NOT to immediately apply all software updates immediately. It is virtually impossible (read that incredibly difficult and expensive) to write perfect software -- I've yet to see any personally. In my experience, it's all too painfully common for one bug fix to cause yet another bug to appear whether it's by breaking something that used to work or by revealing a previously hidden bug.
I've worked at companies that ran through a whole gamut of acceptance tests before they upgraded users' systems to a new release of anything. Their business depended on having a known platform for their users. Think of training, help desk, and the like.
I'm NOT saying users should not upgrade, only that there is a good reason for some users to not immediately install every new fix that comes down the pipe.
Ask the powers that be: How much work could you do in a day if your desk had a 21-inch diagonal?
I used 3 monitors (each attached to its own PC) at my last job. I was doing QA with much automated testing. I was testing interactive web sites as well as database migration, conversion, and update efforts. My monitors? One had a 17-inch diagonal and the other two were 21-inch, as follows:
- 21-inch monitor #1: Input. Here is where I would write test drivers, create input files, and in general produce the stuff that would be fed into the application under test.
- 21-inch monitor #2: Processing. Here is where I'd actually run my tests. I could have multiple browsers or database windows open at once and all visible at the same time. Nothing else was being done on this machine so as to keep it as much like a customer environment as possible. This is the one where I spent most of my time.
- 17-inch monitor #1: Output. This is where I would monitor log files while tests were executing. It was also where I'd run my bug reporting application, process e-mail, write reports, etc. I was pretty much free to do whatever I wanted on this PC without concern for it impacting what I was developing or testing.
I ran the 21-inch monitors at 1600x1200 and the 17-inch at 1280x1024. I shudder to think at how much longer it would have taken me to accomplish anything if I only had one 17-inch monitor to work with!Was it worth it? Let me put it to you this way: The two PC's with the 21-inch monitors -- I purchased them (PCs and monitors) on my own, out of my own pocket. I have no absolutely no regrets. If anything, I'm looking forward to when I can afford to buy another 21-inch monitor so I can run with 3 of them side-by-side.
Persuasion: How do you persuade the powers-that-be to take the plunge? Ask one of them to sit at the computer for an hour as you talk them through your normal daily tasks. Have them remember the stuff that you need to remember as you switch between desktops or windows. Then, go to another PC where you've set up a dual monitor configuration (e.g. borrow the monitor for another coworker). Now talk them through the same task and let them see for themself how much easier and faster to do things without having to memorize so much stuff between actions. You can keep track of more things and less stuff falls through the cracks.
When they feel your pain, and see the benefits, you won't have to convince them, they'll be rooting for YOU! Even better, they may well be thinking of how THEY could get a dual-monitor setup! Encourage that line of thinking, help them to attain it, and you'll have a powerful ally on your side.
Historical Perspective. About 10 years ago I was working at a company that was developing a product that ran on both OS/2 and Windows. Even with my best efforts at scheduling my tasks, I spent from 30-60 minutes a day waiting for the PC to reboot into the other operating system. This was back when a 386-25 Compaq DeskPro was REALLY fast. And expensive ($3000?) so getting dual systems was really tough to justify financially. Today, spending only a few hundred for a new graphics card and monitor should be much easier!
Good Luck!
Have the support group join forces with the QA, Documentation, and Training groups. You are all "customers" of what development produces. Thus, you have a common perspective and interest. In short: work together and share the knowledge!
This is synergy at its finest:
- The Support group learns of a bug from a customer; pass it on to the QA group. They get real-world information on what is important to be tested. If the code has a defect, but no customer encounters it, is it really a bug? When looking at the whole universe of potential inputs to the code, it is a big win for QA to know how customers actually use the product. They can tailor their tests accordingly.
- The QA group, while testing a new release of the product, discovers a bug in unrelated code that has already been released. They can pass that info on to the support group so they are prepared should a customer report it. Saves wasting hours trying to isolate and reproduce a bug -- already have the details. Being able to locate and isolate bugs quickly makes you look good to the customer.
- The Documentation group often finds errors, too. There's an old saying: "If you really want to understand something, try explaining it to somebody else." In the course of writing the documentation, they are going to find things that others miss. Their prespectives can be helpful to QA (Hey, you might want to add this to your tests) and to Support (This feature is complicated and customers are likely to call with problems in using it.)
- The Training group can cut off problems before they happen. There's usually a number of different ways to perform a task with the product. Users often take a "recipe" approach -- they just do things the way they were shown. Training can guide users into a common approach to using the product. The more consistent the customer's use of the product, the fewer permutations that Support needs to be knowledgeable on.
There's more, but I think I've made it clear that there is much in common between these groups.There will come up a time when you have a customer who has a problem, but development is not willing to give a priority to fixing it (maybe they are already behind schedule on the next release). If you discuss the situation with these other groups it's possible that you can provide a united front that will sway development. Or, you may find a workaround of which you were previously unaware.
Lastly, I worked in the QA department at a company where these groups were viewed as a necessary evil; development was king. But, through the approaches outlined above, we were eventually recognized as an ally and were all invited to participate in the design of the next release of the product.
Here's their explanation of the matchbox version of the game:
To keep this on topic: this game could be implemented with a water computer, too. Replace the matchboxes with different colored buckets of water. Instead of removing a bead for a loss, dump out the corresponding bucket.
For a more enjoyable game, replace the buckets of water with shots of beer. =)
No, I don't think a remote would be "all you will need to operate your computer". There was a time when a computer did not come with a mouse, but I'd dare say it's a "standard PC peripheral today." This doesn't mean that they've now dispensed with the keyboard -- it's just another standard control that comes with the PC. So, I take his comment to mean that there would be another standard peripheral that would come with a PC. So, you'd then have: a keyboard, a mouse, AND a remote control.
There is a glaring omission of the ONE language that ALL programmers know: profanity! ;^)
In a nutshell, from what I can tell from over here in the USA, our economy has things good compared to what they're dealing with in Japan.
From what I've read in the Wall Street Journal for the past few years, Japan is in the midst of a long recession. Layoffs have started to be implemented. Banks' financials are shaky and their central bank has pretty much exhausted what they can do (they've got their borrowing rate down to almost zero percent -- can't stimulate the economy much more than that!) Come to think of it, I recall they're actually in a depression -- people are putting off purchases, now, because they'll be cheaper, later. So businesses are starved for income and cut prices to drum up business; lather, rinse, repeat.
I'm not saying you shouldn't go, but I most certainly would advise you to take a long, hard look before you leap.
One thing I didn't notice in your post is how knowledgeable you are with their language? There are 4 parts to learning a foreign language: reading, writing, speaking, and listening. I studied German in High School and am still able to get by with the reading and speaking, but listening was hard (different intonations and accents) as was the writing (like programminng in a language I didn't know too well.) At least German uses basically the same alphabet as English (with the addition of some umlauts -- the two little dots over vowels). Japanese -- you need to learn a whole new alphabet, let alone the vocabulary and grammar. You've got your work cut out for you. And, if you've never learned any language other than English, doubly so. It was a real struggle to learn German in high school -- it was a whole new way of thinking. It's not like I'd think of what I wanted to say in English and do a literal translation! I had to learn to THINK in German. But, having done that, it's much easier for me to learn another language. I am now in the process of teaching myself ancient Greek and it's so much easier because I've already learned how to learn a language.
In the interim, have you given some thought to going over there for a month or two of vacation? Then you'd have a chance to get a real feel for what things are like over there. You may well find "It's a nice place to visit, but I wouldn't want to live there." But, having spent some time over there, you'll have some great experience that you can leverage should you decide to come back. I can assure you, you'll not see the world in the same way again! I was fortunate to have had a job that paid me to work for a week or two in 5 different countries in Europe. It truly broadened my horizons!
It's good you are soliciting feedback and I hope you are able to garner useful information from people who have actually lived there. So, here's wishing you the best of luck in whatever you decide.
P.S. One last thing: practice using chopsticks. =)
Great. Just Great. First it was downloadable ring tones. Now it'll be customized voice filters. I can just see the advertisement now:
Wired has more details
Their story appeared today
It can be found here.
This is not as strange as it sounds. (pun intended) I've seen precursors to this, and have actually experienced something similar about 25 years ago.
I see this research as an interesting step that continues along that path.
As for me, I'm much more a visual person than auditory. I'd find it much more valuable if I could "see" my program execute. Once in a while, I've messed things up with my postscript printer and the listing came out at what appeared to be 1 point sized text; at 300 DPI, that worked out to being about 5 dots high. At times it was almost possible to make out the words, but realiistically, it was too small to be legible. But it WAS sufficient to show the structure of the program, especially since I consistently use indentation. If different colors were used to denote different structural items (conditional, loop, assignment, key words, etc.) AND there was an indicator that would highlight each statement as it was executed, then I'd be able to see the actual flow of the program. I could tell what functions and subroutines were executed most often. Hmmm, this seems like such an obvious idea... does anyone know if such a tool already exists?
On another note, It would be interesting to combine visual profiling of a program with a touch screen -- I could use different gestures to debug my program! Double-tap to zoom in/out on text; single tap to set a breakpoint on entrance/exit of a subroutine, etc.
Two situations come to mind.
The first is not so much a specific bug that was difficult to find, as it was the general means that I was forced to use to locate bugs. (Yes, I found quite a few.) Back in the early 80's I was working at IBM in the QA group responsible for testing their VM operating system. We were tasked with taking the existing VM OS and not only were we to improve its performance on multi-processor systems, we were also to improve its reliability by doing extensive reviews and testing. I was responsible for testing the free storage allocator.
Some background: For those who may not be aware, that whole operating system was written in IBM BAL (Basic Assembler Language) using the 370 instruction set. The VM operating system created a virtual machine environment for each user - thus producing the appearance of a machine, identical in [almost] all respects to running on the bare hardware. Those few differences pertained to some optimizations in the the virtual memory management's use of PTLBs (page table look-aside buffers) among others.
So, I needed to test memory allocation on the bare hardware to make sure that it worked okay. Once that was nailed down, I had to test memory allocation when VM was running on VM. But, there was yet another set of optimizations that I needed to test when a VM was running on VM running on VM (i.e. a "3rd level" VM).
It was not possible to just issue VM commands to test the various code paths. So, each test consisted of setting hardware breakpoints at the appropriate hex offset, and single stepping through these allocations. By the time I got to testing the 3rd level VM code, I was tracing and debugging these PTLB calculations and allocations, single stepping through instructions in hexadecimal and verifying multiple levels of indirection to memory pages where those calculations were also in hex. Those were the days! Just a year or so out of college, and I had all to myself a multi-million dollar mainframe computer that could support several hundred people!
The other bug was actually a specific bug that caused much early hair loss. I was working at a place where there was a lot of new employees come on board. Along with that, new departments were being formed, people were being promoted and moving to different groups, and there was a great deal of office moves as a result. So, it soon became a problem finding somebody's office. "Gee, wasn't Mary here just last week?"
Sensing a need, I wrote up a quick REXX program (yes, this was back in the early 80's, too) which did data aquisition through forms and supported the generation of reports sorted by various categories: Name, Department, Room Number, etc. This was pretty straightforward and in a couple days I'd gotten it coded, tested, and all the data populated. As there were only a few hundred people I used a flat file (the other alternative was creating a DB2 database and disk space was very dear back then!)
Rolled it out and received much positive feedback. Except, there was one person who noticed there was an error in the ordering of room numbers. See the format was: "Floor: 1, 2, or 3"; then the "building wing: compass direction: N, S, E, or W", and lastly, "room number: 2-digit number". As this was a rapidly growing organization, managers would be allocated several empty offices in advance for the people they'd hire during the next quarter. Also, the building had just been constructed and some areas and sometimes whole wings were still not yet ready for use so there were many gaps in the data. Here is a selection of the kinds of results I saw for the room numbers, in ascending order:
Why are the rooms in the South wing nicely ordered, but things are really messed up for the East wing? I spent HOURS and HOURS trying to figure this one out. See if you can tell what the problem is before reading ahead.
The problem? There is a single set of comparison operators <, =, and > and they just did the right kind of comparison depending on the data type of the operands. Well, here I was thinking the data was text, but the program was making the comparisons as if these were numbers that contained an exponent part
answer: 1. sound is much slower than radio waves, so the electronics can be slower and simpler (and therefore cheaper). To "slow down" a radio signal, you'd need a large diameter ring of sensors -- something that may not fit on top of a launch tower
Thanks for the feedback! It prompted me to do some calculations and further investigation. Apparently, there are TWO different SOLLO systems: SOLLO 1 and SOLLO 2. (Note: There's an error in the HTML for the SOLLO2 page where a less-than-symbol can be mistaken as the start of an HTML element.) Here's the description for SOLLO 2:
So, to answer my own question of why not use just RF? The speed of light is approximately 900,000 times the speed of sound; let's just call it one million (10^6) to make the calculations easier. Then, the differences between times of the arrival of thunder at the five AM receivers would range up to a few nanoseconds and the differences would need to be determined within 10 picoseconds. Ouch! I'm no electrical engineer, but that looks like terahertz to me. Getting it back down to gighertz would require expanding the baseline by a factor of 1000. That implies arranging the RF receivers around the perimiter of a circle 2 km in radius. SOLLO 2 would fit in the back of a pickup truck; mine wouldn't be quite so portable. =)
I was pondering this very thing a few days ago when a lightning storm passed by. I turned on my AM radio and discovered there was quite a range of frequencies that would pick up when there was a flash of lightning. So, my thoughts were to use a number of AM radio receivers, arranged equidistant around a circle, each sending their signals to a processor located at the center of the circle.
Now, it appears that the NASA folks are using microphones to pick up the sound of the thunder. Thunder is just the noise made by the lightning. Why not pick up the RF field, itself? I would think there would be less distortion and a clearer signal. Instead of 4 microphones, use 4 AM radios. Otherwise the technology would be the same in measuring the path differences (which was so clearly explained in the parent post).
Now, I'm aware the RF signals can also experience distortion (multi-path, etc.) so I'm not claiming that AM receivers would be a panacea, but I would think that it would be more precise than anything that could be done with microphones.
The preceding is based on what I'd learned in physics classes back in college... Is there anyone here who is more versed in RF signal processing who would care to comment?
I have no expectations that a means of blocking gravity have [or will] be found. But, if it should come to pass, I have only one question:
(For the humor-impaired, that was supposed to be a joke.)Does anyone here ever *think* they achieve this Flow State while coding?
Most definitely... often 2 or 3 times in a day. Never before thought to associate it with meditation, but I can see similarities.
My own experience has been that when I am in the zone, there's a certain balance:
By no means is this an exhaustive list; it's just my own experience. Yet, I suspect many of these factors are true for others. Through it all is a sense that things are within my "comfort zone"; neither too much nor too little. There's also a sense of continuity whereby each small success builds on the next until there's a sense that the next challenge can be readily solved, too. When that happens, I have no sense of the passing of time, I can see the minute details along with the big picture and all the levels in between.
In short, I'm receptive to what's coming in, I'm experiencing pleasure in what I'm doing, and I'm successful in what I'm producing.
Why does anyone need this? Even my grandmother, who is not very good with computers, can remember the sites that she likes to check every day. She can click the little "Bookmarks" menu, or even *gasp* type in a URL. So, if even the simplest computer user can get through their daily web routine without a "metabrowser", what's the point?
I'll agree that for most users at home, this doesn't seem to make much sense at first. But, there are a couple of cases in which this could be helpful.
The devil is in the details, though. Just how well does such a service work? They need to make a good first impression. Don't keep showing me stuff I'm not interested in, but also don't keep missing out on things I AM interested in! If there were a simple way to do it with technology, then there'd be no need for the editors on /. to sift through article submissions.
It could be argued that I should just get a lap top or a PDA with a wireless connection. Yes, that would be nice, but that's not a viable option for me at the moment, economically. Maybe in a few years when the upfront and ongoing costs of a wireless PDA has come down some more. My ISP provides unlimited dial-up access for my home PC at $20 per month. We're nowhere near that for mobile access and it's just out of most people's price range.
So, though I see some value to the concept, I don't see much of a market for it, now. But, over time as the costs go down and the capabilities improve, I can see this becoming increasingly useful.
I've also got an older Compaq Presario 1675 that has
1) broken/cracked usb port
2) cracked lid near hinges
3) 1 Hour battery life (I know, I need a new one)
Here Here! I've got an almost 5-year-old Compaq Presario 1610 that has been through the wringer and just keeps running. It survived a dozen flights, hundreds of rides on the floor of my car during my 25 mile commute to work. As I also generally carry a backback, the normal approach for me was to toss the laptop carrying case over my shoulder, and then throw the backback over the same shoulder with all its weight pressing upon the laptop. Took it like a trooper and it Just Keeps Working.
Unfortunately, it's a 150 MHz Pentium MMX; its RAM is maxed out at 80 MB, and the 1.6 GB hard drive runs 90+ percent full. So, I've been looking around for a more capable laptopn. I'd been eyeing the Dell Inspirons, but from what I've seen here... I'm definitely reappraising that idea. I've seen a couple suggestions for IBM laptops; does anyone else have a recommendation?
Though it was years and years ago, I'd done some 6502 assembler programming. In fact, I just pulled out my copy of "Programming the 6502" by Rodnay Zaks (Sybex Inc.). I was never that good at it, but I had a lot of fun trying!
Unfortunately, when I tried to download the binary ROM image of the 6502 code on his web page I got an error: Cannot find the file specified.
If/when that gets fixed, the next step would be to get a computer do the work. A quick check of google using the search string: "6502 disassembler" brought up about 337 matches. Granted, some of the disassemblers are designed to run on older hardware (e.g. Atari, Commodore 64), but I saw links for unix, windows, and DOS, too.
Screw Halo! Imagine playing PONG on this thing
You may laugh, but that sure brought back a memory. Back in 1981 I was in college and working at the student union setting up for a concert later that evening when one of the building's directors wheels in this big, bulky thing and starts to roll down the 20-foot diagonal movie screen. Come to find out it was a new projection TV system. (Films were popular on campus, so the thinking was why not project videos, too?)
A lightbulb went off and I asked "What does it use for inputs?"
"Basically any NTSC source; there's antenna connections and RCA jacks."
Within 15 minutes' time, I'd hooked up my Atari 800 (*) to the projector and to the concert sound system (1000 Watts!) and started Star Raiders(**). The explosions were deafening, and when I launched into hyperspace, it sounded like a jet was taking off in the student union! Got to play for almost an hour until some students complained they couldn't study.
(*) That was a 6502 (8-bit) system. IIRC it ran at 2 MHz; had 8 KB of memory; display was in color and capable of 12 rows of 40 characters. It was pretty advanced at the time!
(**) Star Raiders was a killer app of the time. Many people bought an Atari 800 (or 400) just so they could play it! It was certainly a big factor in my decision.
The developers of the hardware usually aren't the ones who are lying.
Agreed! I've seen that happen more than a few times. Thought it might be useful to add another possible reason why some features are hidden.
My expertise is with software (20+ years in QA), not hardware, but I've seen the hiding of features happen several times. In my experience, the develpment cycle starts off with marketing making its pitch for what needs to be in the product release, and development pushes back with what is feasible in the time frame, as well as what they would like to do. There's some negotiation, and then development goes off to "do their thing". And all is happy and good.
Then QA appears and does its thing. Sometimes QA is called in right from the start; other times the product is almost ready for release and someone thinks it might be good to have QA look at it before it is shipped tomorrow. I actually have seen a few projects released on time, under budget, and with the promised capabilities. But, that is sadly the exception rather than the rule. Even with an early participation by QA, there are often far more developers at work than QA people. The number of possibilities goes up exponentially, and there's just not enough time to test everything as it is developed. Design errors and implementation errors are found. Rework is required. Deadlines loom. All is not as happy and good as it once seemed. And then it happens.
Maybe it's a nasty memory leak that builds up over time. Maybe there's a variable that gets corrupted, eventually. And there's not enough time to isolate it and fix it. So, instead of yanking out all the questionable code (which would introduce its own bevy of problems), the common approach is to just remove access to it (e.g. removing a choice from a pull-down menu) and, of course, removing all reference to it in the documentation.
So, there's quite possibly some hidden functionality in a program (or a piece of hardware), but it was hidden for a reason. If you're a bleeding-edge kind of person, go have fun. In light of your particular circumstances, it might well seem to work okay. But, if you need to be able to rely on the application or system, it might be a Really Good Idea(TM) to use only the documented features. You might miss out on some helpful features, but you might also save your butt.