Such nonsense can be disabled if it gets in the way of your working.
I looked and I looked and I looked, but I couldn't find any way to disable the "crash every couple of hours taking out all changes" option. Neither could I find any way to disable the "lock the application solid every 30 minutes so I have to kill it without saving." option.
I can put up with it drawing funkly red and green lines where it thinks I'm doing the wrong thing. Fact is, like that other fellow, I'd rather complain than set it to not do that. At least that way, the two or three percent of the time that it's pointing out a genuine error, I can get some use out of the feature. However, a word processor that crashes and locks up and loses data randomly is not something I'd wish on my worst enemy.
My preference is to use LyX. The documents that are produced by LyX may not be as pretty (as near as I can tell, the reason that the spec I wrote was converted into "Word" was so we could put the company logo on the title page) but it's the content of the document that's important, isn't it? Besides, LyX has never eaten any of my data and refused to save it when asked.
There are four categories of defect. They correspond roughly to the severity that others have talked about, but say nothing as to the order in which the defects are repaired, which is set by priority. Generally, all defects discovered during testing will be repaired before shipment.
A category 1 defect is when, for some combination of inputs the program either automatically restarts or stops responding to communication requests. (That is, it either crashes or locks up.)
A category 2 defect is when, for some combination of valid inputs, the program produces the incorrect result.
A category 3 defect is when, for some combination of valid inputs and at least one invalid input, the program produces an "unreasonable" result. (The rationale is that, generally, errors should propagate so input errors are flagged on the output.)
A category 4 defect are all other errors, generally they are cosmetic errors, misspelled menus, odd cursor positioning, and so forth.
No category 1 or 2 defects should exist in released software and category 3 defects should only be permitted if the repairs will have a strong negative impact on the schedule. (I have never shipped a product with any but category 4 defects.)
The whole "valid" vs "invalid" inputs may confuse some people, so I should probably explain. I'm used to working in embedded systems where the system reads some measured values. Typically, those values will be represented to the system as a current, a voltage, or a contact closure. The "4 to 20" current loop is typical of the sort of thing I'm talking about. In that sort of system, the physical value is calculated from the current in the loop which varies from 4 mA to 20 mA. If the current is within that range, then the interpretation is easy. The question then becomes what happens if you get 0 mA or 22.5 mA? Neither of those is valid current as far as the system is concerned so it's not clear that the normal conversion to measured value should apply.
However, you will see such values in practice. The first is what happens when the wire gets cut, the second might be the result of an uncalibrated transmitter. A large part of the design of an automated control system has to do with figuring out what to do with those out of range values.
However, other sorts of programs get presented with invalid inputs, so the approach is not without merit in the more typical case. If, for example, you present a COBOL compiler with 6 MB of random data (as an acquaintance of mine once did) it shouldn't crash and should give you some kind of helpful error message. If it did the first, it's a category 1 defect, if it didn't do the second, then it's a category 3 defect.
The first run lasted considerably longer than 8 weeks. I can recall watching "Star Wars" at the Raintree Cinemas during the last week of the first run more than a year after it opened.
Well, consider the fact that in each PC there are at least two (in the keyboard and the hard drive) embedded processors and maybe more. (Modems and network adapters have embedded processors, that optical mouse that Microsoft sells has at least one processor in it, some video cards and some monitors have additional processors, and so on. Not to mention the fact that there may be more than one hard drive.) It's real easy for me to believe that PC's are a small minority.
Add to that the fact that most every wired telephone, all of the wireless phones, all of the TV's, VCR's, stereos, remote controls, calculators, and so forth have embedded processors in them. It adds up, and quickly.
The only problem I had with the story is the implication that embedded systems are a new thing. When I started doing embedded systems in 1991, most or all of the names that they mentioned as dominating the real-time OS market were already well established. The embedded systems themselves were the very first application envisioned for microprocessors. From my perspective, embedded systems aren't the next thing, they were the first thing. I guess the rest of the world is just now catching up.
If radio stations are getting more money from advertisers, then generally it's a good idea to pass that along to the talent. That's what keeps the talent from going to a station where they will pay what the talent thinks he's worth. However, it's not been demonstrated to my satisfaction that streaming their content is all that beneficial to the stations' bottom lines.
Several people have commented on how greedy the stations are who won't pay an air personality triple his salary to stream his program. Don't you think that if there were large profits to be had for those stations that streamed their content that they would pay up? Loudly complain about the cost, certainly, but pay up anyway just to get the extra revenues. Greed can work both sides of this particular street.
Only about three year's worth. It's not like I can go out at drop a grand or two on a video card in the hope that I might be able to make it work, as you apparently can.
sydb also wrote:
For best-class gaming, get a high-end NVidia card. Get the linux drivers here. They provide detailed information about requirements and setting it up. The driver is currently closed-source, however, so you are dependent on NVidia's continued support
So, if I walk into Best Buy, I can ask one of the guys in a blue shirt for a "high-end NVidia card" and they'll hand me a box labelled "high-end NVidia card" and I'll buy it and take it home and be happy? I don't think you read my post.
This is not to mention the fact that, of the three games that I mentioned as owning or being interested in owning, none of them are able to use the NVidia cards, according to the system requirements label on the box.
This is also not to mention that the computers that I own already have 3D accelerated video cards, but only under Windows. It is most uncool to have to boot Windows-NT to play Quake-II, which I've only purchased the Linux version of.
sydb also wrote:
For a cheap, no brain option, get an old 16Mb 3DFX VooDoo 3 based card. Lots on ebay at very nice prices. Well supported in XFree.
Right. See the above question about "Best Buy". (I didn't see anything resembling an "old 16Mb 3DFX VooDoo 3 based card" either there or at CompUSA. Maybe I should try Fry's. After all, it's the last day of their grand opening today.)
As for the prices on Ebay, well, I looked on Ebay some months back and I attempted to determine that the precise cards being sold had support for 3D acceleration. This is because some VooDoo cards won't work and I don't particularly feel like wasting time and money on solutions that don't work. As near as I could tell, of the inexpensive cards being offered at that time, none were supported under Linux. I already have 3D accelerated hardware that doesn't work under Linux, thank you very much, I don't have to buy any more.
sydb also wrote:
You'll want to use XFree4 of course, to benefit from the 3D hardware acceleration in the Direct Rendering Infrastructure (DRI).
Yes, of course. That's why I installed XFree86 4.0.1 as soon as it was available for Debian Unstable and why I was disappointed that it wouldn't work with the same video adapter that does 3D acceleration just fine under Windows. However, if you want to run one of the three games that I mentioned as owning or being interested in, they say they don't work with XFree86 4.x's 3D acceleration. Again, I'm not interested in pursuing solutions that are documented as not working.
In fact, I'm wondering what you run with your 3D accelerated video under. Nothing that I'm interested in seems to want to use OpenGL. Except for the screen savers, of course, and they work just fine on both the computers I routinely use, even if they are slow as snot.
The non-comercial Linux users do not like to buy software, ever. No one will make money becuase you dont buy.
Who are these "non-comercial[sic] Linux users" that you are talking about? I can't speak for any other Linux user, but I don't mind paying for software. In fact, many Linux users actually do pay for software. This is known because that software is the games that people talk about having to reboot into Windows in order to run.
I can, however, talk about why I don't buy Linux games. So far, I've bought three of them. I've got "Civilization, Call to Power", I've got Quake II, and I've got Quake III. (I can definitely confirm the poor sales of the last. The Half-Price Books near my house has maybe a dozen copies in those cool limited-edition tins.) Of those, the only one I paid full price for was CivCTP. I chose to pay full price for CivCTP in order to support Loki and encourage others to produce games for Linux.
My primary difficulty with the current crop of Linux games is the fascination that those who create those games have with 3-d acceleration. I don't know the incantations needed to get hardware 3-d acceleration under Linux. I haven't yet been able to figure out which card to buy that offers 3-d acceleration under Linux or which software to install to cause it to occur. I go to Web sites like
Linux3D.org and I leave more confused than anything else.
In particular, the cards that are on sale down at the local Best Buy don't seem to correspond to anything listed in the compatability list.
So, I've bought these games (and the Half-Price Books has Heavy Gear II for Linux for $14.95, but I haven't purchased it) but I can't play them because they require stuff that I don't have. Maybe if someone ported a game that didn't require hardware 3-d acceleration, it would sell better. I know I'd be more likely to pay full price for it.
If your ISP used NT servers as terminal servers (as opposed to Portmasters, MAX's, Cisco, etc.), then they *would* have to pay for a client license for every line that would be in use at max capacity.
There seems to be some confusion.
PM-4's and Maxen and Cisco's AS-5x00 series equipment are all called "Terminal Servers" but they aren't the same things as what Microsoft calls a "Terminal Server". If you had an NT box that just answered the phone and set up PPP sessions with people, you don't have to have a Windows license for everybody that connects.
From the Microsoft perspective, Terminal Servers seem to be computers that run applications that appear on terminals. That's quite a different thing.
Of course, if I'm the one that's confused, you should feel free to ignore this.
People are like people everywhere you go, but sometimes you have to interpret their actions in the context of their society to see that.
It's most likely going nowhere in Texas and the article shows a profound misunderstanding of how Texas politics work, and considerable intolerance. I mean, one legislator proposes one bill out of the thousands that are submitted for considertion before the legislation goes out of session and it's supposed to reveal how all Texans think about all things? Does everyone in your neck of the woods think exactly alike? About all issues?
I guarantee that the background and focus and political bent of a typical person down in the Rio Grande Valley or up near El Paso or deep in the "piney woods" of East Texas are different from the people in more urbanized areas like Houston or Dallas or San Antonio. Even then, 100 people from even from the same area and socioeconomic class will have 100 different political beliefs and backgrounds. That's the way it works in the rest of the United State of America and that's the way it works in Texas, too.
The Texas legislature is only in session for about six months every other year, so you see a burst of all kinds of bills submitted right before the deadline for the session. Most of those bills, including this one, haven't a snowball's chance of passing. Some do manage to pass, but are in a form that, except for the bill number, is completely unrecognizeable as the original bill. If the committee is leary[sic] of the bill, it'll likely die there, possibly to be resurrected in 2003, but I doubt it.
Postgres 7.x is supposed to be dramatically faster... I haven't had a chance to do any benchmarks - has anyone else? Personally I'm hoping Postgres takes off and we can switch to it from MySQL (for triggers, transactions, etc).
I've used PostgreSQL since it was Postgres95 and each major version seems to get much faster, (as in the same query executes in 1/3 to 1/2 the time.) However, I know nothing about running real benchmarks on database systems, so I can't quantify anything. I can only report my impressions, and I think that PostgreSQL is plenty fast enough for use in just about everything you'd use MySQL for.
I'm known to be biased, so make of that what you will.
Temporary?! Bullshit. Do you have any idea how much 2^128 addresses is?? It's enough for every person in the world (assuming 6 billion people) to have 5.67E+28 addresses each! There's no way we will use all of those before networking as we know it is completely redesigned.
You've completely left out the efficiency factor from your calculation. While it is true that IPv6 allows a standard metric buttload of addresses, the system is set up to assign those addresses quite inefficiently.
For example, the standard assignment for an individual end user is likely to be a/64, which has appriximately 16E18 addresses in it, of which only one will be used, typically. Small ISP's like myself are currently assigned a/48, which has enough addresses for 65K end users, of which only a fraction will ever get used.
Of course, should the address space starts to become exhausted, what will happen is what always happens when a nonrenewable resource becomes scarce: conservation, but for right now IPv6 addresses in freaking huge blocks are easy to get. I've got 2^80 addresses, myself.
To answer the question asked in the subject, the reason the blocks are so large is because the routing tables would quickly become huge if the assigned blocks were smaller. That means that ISP's will likely assign blocks to end users and not worry about whether or not those end users assign those addresses to multiple computers. It's more work than it's worth to keep track of those addresses individually. NAT will still be around, though, because people like the additional security offered by it.
It's not an inappropriate comment, seeing as how tax cuts which benefit primarily the rich are Bush's number one priority, which certainly affects NASA's budget.
Actually, the tax cuts necessarily benefit primarily the people who pay the taxes. People who are poor pay no federal income tax so they cannot possibly benefit from a tax rate reduction. Since people who earn more than $50,000 a year pay essentially all the income taxes in the United States, people who earn more than this, (the population that people like you tend to define as "rich" in order to make the "only the rich will benefit from a tax cut" statement true,) are necessarily going to reap essentially all of the benefits.
Myself, I'm one of those "rich" people who pays my share of those income taxes and probably a goodly chunk of yours, too, and I'd like to point out that it isn't the government's money, it's mine, and I'd like to be permitted to keep a little more of it.
It has been posited that your work was done as a "work for hire." (Your contract should specify, but I expect that it almost certainly is.) If that's the case, then you don't own the copyright and you don't get to choose the license.
If, as you also say, that nobody with the authority to choose the license understands what you wanted when you proposed to release the code under GPL, then you did not, as you say, "follow the appropriate steps for applying the GPL to the software" which include, as a necessary step, getting the owners to agree with releasing the code under the GPL and understand what that means.
You can't trick someone into accepting the use of the GPL by keeping them ignorant of what that means and so, if you don't have the authority to make that decision yourself, you have to make the persons in authority aware of the ramifications of that choice. If I were in that situation, I'd apologize profusely for overstepping my authority and put together a document directed toward the decision-makers explaining the benefits of releasing the source under the GPL.
Further, I'd avoid lengthy discussions on the putative benefits to society for using the GPL and focus on things like potentially spreading the support burden over a larger customer base. Maintaining home-grown software is expensive and you might be able to justify that choice of licenses based simply on that. That's more likely to go over well with people who don't view this as a moral issue.
You're not addressing his point - there are other countries that allow large companies. They don't necessarily afford them legal status as "people", which is what the american decided to do to get round that pesky constitution thing you folks have.
Actually, the USA inherited that idea from the British who stole the idea from the Dutch. It has nothing to do with getting around the US Constitution and everything to do with sharing the financial risk of paying for a manufacturing business. I'm not aware of any country in the world that doesn't have corporations, which is what you describe when you talk about giving a company the legal status of a person. Certainly, all of the North American countries have corporations as do all of the European Common Market countries.
I disagree strongly with the statement that using glibc-compat isn't a solution for a production system. In fact, I'd rephrase the statement to be "You can, however, use the system that was put in place for just such a purpose, but that isn't a solution for a production system."
The people who came up with glibc-compat did so because they anticipated the difficulties associated with upgrading the systems as a whole to newer libraries. There's nothing wrong with installing the older libraries and they're not something that should be avoided for "production" systems.
To be sure, it would be nice if Oracle got with the program and updated their tools to run on a more recent glibc, but until that happens, you have an alternative to sitting around, scratching your head, and saying "Gee, it doesn't work." That makes more sense than the "you should statically link all major applications" crud that others have posted.
Whenever the "barriers to entry" (i.e. initial fixed costs) of running a business are low, then many people go into business and compete with each other. Due to this competition (competition==good thing), profits become lower and lower. Finally, the razor thin profit margins means that only a large corporation can make any substantial profits, driving the smaller companies out of business.
Ummm, no. Or, at least, not necessarily. There are substantial diseconomies of scale associated with business, and in a service business like the ISP business, there are few or none of the economies of scale that are associated with manufacturing businesses.
For example, the total tech support payroll at the small mom-and-pop (I'm the "pop") ISP that I own is smaller than SWBell's payroll for tech support managers. Those tech support managers don't provide tech support, but they do add to the cost of providing tech support. Therefore, tech support is easier to afford for the smaller ISP than for a company like SBIS.
Of course, the razor thin margins are there and cause failures, but the companies that tend to fail are those that borrowed a bunch of money, (or sold a bunch of stock,) often to buy up smaller companies, and have discovered that they can't make enough beyond their overhead to make the interest payments. In this case, the small ISP's are the ones being bought, not the ones doing failing
Anyway, two things have been obvious to me for some time. First, providing access to the Internet to individuals is not going to be a license to print money, like people were thinking it was going to be five years ago. As you say, the barriers to entry are too low for that to happen. So, the successful ISP will need to focus on other areas to make most of their profits. What Brokersys tries to do is to have the dial-up stuff to pay for its share of the fixed cost, but we make most of our profits on other things. Second, many people will pay a premium to buy their Internet from a smaller company. It is, therefore, a mistake for a small ISP to try to price themselves like the big discounters.
Or how about the hundred times I've asked where I could start from to be able to tweak the virtual memory management of Linux because I have certain needs to take care of. No one can tell me. I suppose I could meditate in front of that humongous 2.4.0 call trace poster.
You know, someone who was used to working with medium-sized C programs and who wanted to tweak the virtual memory code would probably just cd to/usr/src/linux/mm (where I simply guessed that "mm" stood for "memory management") and start there. The Linux kernel is organized fairly well and is no worse documented than most of the source I've inherited over the last 10 years of embedded-systems programming that I've done. However, you do have to be prepared to do some detective work on your own.
Just about any large project is going to be, as you put it, a "zoo" because it is tough to write large programs. Programmers that expect to spend any time at all working with other people's source are going to anticipate this and develop a toolkit to deal with it and, although it is difficult to become familiar enough with a source set to find your way around it without trouble, the more experience you have with the source set, the easier it is.
There is no hard and fast rule. If the implementation sucks, then you need to rewrite it. If the design sucks, you need to redesign it. Of course, determining whether it "sucks" enough must be left up to the judgement of the programmer. However, I have learned that the phrase "this can't possibly work" generally indicates that the speaker doesn't understand whatever it is well enough to tell whether it sucks or not.
My own personal belief is that the desire to not redesign is far more powerful and needs to be guarded against far more than the desire to redesign. However, you need to keep backup copies of everything in case you make a mess of things. I've never understood why some programmers just start making changes to their source without making sure they can get back to where they started.
As for selling it to your superiors, well, if you're the programmer, it's properly your decision, not theirs. You don't ask them for permission to do it, you tell them that this is what needs to be done, or maybe you tell them that this is what you did. You're the only one who is in a position to tell whether the least effort approach is to fix or replace, so act like it.
Sure, it's usually a good idea to consult with people of differing perspective and varying experience before taking any drastic action, and you must consult with the other programmers any time your changes might affect what those other programmers are doing, but if you're the programmer, you should have the final say in how the programming goes.
If you can't make that stick, and I haven't always been able to, you can always use your coffee break time, lunch hours, the odd evenings, and sometimes weekends to do your rewrite or redesign as a kind of a "skunk works" project. I've done that a time or two, but you must guard your time off jealously. If they already expect you to work evenings and weekends, then it's probably best to put your CV out. In this job market, there are other places to work.
At the same time, note that countries that spent little money on Y2K are substantially less computerized than the US.
Not universally. Italy, for example, didn't spend 1% of what the USA did on testing or fixing the "Y2K" problem and they are every bit as computerized as the USA and had the same level of problems.
Nothing happened thanks to his warnings. I have friends who work in banks, and according to them software did not run in the first "set-the-clock-forward and see-what-happens" tests.
You don't think the fact that most time-dependant programs generally make the assumption that the clock isn't going to make large jumps either forward or back could possibly have contributed to those failed tests, do you? The fact that there were more problems attributed to the Y2K testing than to the actual event indicates to me that most of the effort to "test" for "Y2K compliance" was not just wasted, but actually harmful. (In fact, I got bit more badly by a misguided Y2K test than by the sole Y2K bug that hit me.)
There are two things to learn from Y2K. First, you can't test the time-dependance of software by simply resetting the clock. To properly perform the test, the state of the machine has to be updated to match what it will be when the date in question actually arrives, not the state it happens to be now. That is difficult and is not usually easily accomplished. Setting the clock back is even harder.
Second, there are classes of bugs and not all are harmful. The errors that were actually seen (of which various Perl scripts printing 19100 for the year starting January 1, are a prime example) were exactly what I believe we'd have seen more of if all the hype hadn't happened. I expect that if you put the power plant control software from two years ago into the plant's computers now there would be absolutely no change in it's operation because control software typically doesn't know or particularly care about what the date is.
Please note that those countries and companies that spent very little on "Y2K compliance" had about as many problems as the USA and Canada and those banks and airlines that went through all the nonsense. If it had such a potential for disaster, shouldn't we have seen at least one life-threatening failure somewhere? Perfection is difficult to achieve in practice and so saying "it would have been a disaster, but for the efforts of those raising the alarm" because we've apparently somehow achieved perfect Y2K compliance is a bit hard for me to believe, especially in light of the disastrously ignorant way many organizations approached their Y2K testing.
In short, I believe that the world wouldn't have ended or even been inconvenienced even if all the consultants hadn't existed and none of the hype had occured. I'm sorry that it hurts the feelings of one of those consultants for that to be a common view, but I don't believe that it's an unreasonable view and my sympathy is tempered by the amount of hassle and extra work I had to go through because people like Peter de Jager and Ed Yourdon spent the last decade whipping people up into a unreasoning frenzy so they could make twice my income selling technical armageddon seminars to the PHB's.
Now that's one heap of BS.
Let's go back to when computer gaming became mainstream. The 1980's and the C64. What were the most successful games doing then? Pushing the hardware to it's limits. Same thing with it's successor, the Amiga. The same thing also happened with console games.
You have selective memory. Some games have always pushed the hardware to its limits, but the reason that PC's had "turbo" buttons for years was because most games, and turbo buttons were all about games, did not push the hardware and you had to slow a faster than standard computer down for them to be even near playable. Most console games even then didn't come anywhere near taxing the hardware they ran on. Some (and here I'm thinking things like Atari chess) did, but it was less about graphical displays than it was about limitations of RAM and ROM. The graphics were intended to be competitive with the often specially-designed arcade equipment and, for the most part, achieved that easily by including similar hardware.
Carrion also wrote:
What about the coming of FPS games then? When ID software released Wolfenstein 3D they did things not thought possible with the hardware. Turned in a lot of money. DOOM got them heaps of it after that since they had ditched their distributor and were good at it themselves. Same thing here. Quake a bit later made people drool at the realistic, fast 3d. After this the ID programmers were driving Ferraris...
And how many other game programmers, all of whom are writing games that require substantial upgrades to the typical Windows computer just to run, are driving Ferraris? Damn few. Isn't it just possible that, given the success that some people have while writing games that push the hardware when others fail utterly, even though they push the hardware every bit as hard, that the success doesn't really have that much to do with how extreme their performance is?
For what it's worth, I think Id's commercial success has more to do with having a coherent and enjoyable vision and wise business practices than it does with advancing the state of the art in graphical displays. The pushing of the hardware to new performance levels was a side-effect required because the older techniques weren't able to support the vision. But the vision came first.
There is no doubt in my mind that Id's vision is always going to take the hardware to its limits, but that's the sort of games they design. Other designs are not nearly so hardware intensive. (How many megapixels/sec do you need to do a "Tetris", anyway? I would expect that more people play "Tetris" and "Mahjongg" daily than have ever played "Doom", "Quake", or even "Wolfenstein 3-d".) The fact that other sorts of games can be every bit as enjoyable to play and not tax the hardware proves my point.
Carrion also wrote:
Oh yes, using the hardware to the max really makes a money loser...
Not necessarily, but making a game that uses hardware "to the max" does not necessarily make a game that is a money-maker. It's the emphasis on technically duplicating "Quake" without really understanding what makes "Quake" playable that makes for money-losers. Your counterexamples don't disprove my opinion because they are so rare.
Carrion also wrote:
Oh sure, you're right about that. But what do most 3d artists want, to be able to produce better visuals? More polygons, more and higher resolution textures, better effects... And still at a good framerate.
How do you know? Are you a game artist? I am willing to stipulate that that is what the visual artist might want, but what does the game designer want? I'm not talking about some crap derivative game designer who is trying to duplicate "Quake" or "Half-Life" or "Diablo" because he thinks, as you apparently do, that simply duplicating someone else's success will get you a Ferrari, too. No, I'm talking about someone who has a different idea of what people will play.
You can't tell me, because you can't imagine such a person.
If you know a thing or two, you will not make such absurd remarks. cross-platform engine for game development? Are you on crack? Do you know what it takes to write a game? What developer in his mind wants a dumb mediocre engine just cuz it is portable?
Perhaps one that had a game with good gameplay but not so flashy graphics who wanted to sell to as wide a market as possible? Many people believe that this thing that you also wrote:
Game programming is about pushing the hardware to the very limit.
Is so wrong that it's not even funny. Game programming is about producing an enjoyable game, not about throwing megapixels on the screen. The whole "pushing the hardware to the very limit" BS is a fairly recent phenomenon, and may be the reason that PC games (not just the Linux ones as reported on/., but PC games in general) typically are money-losers.
In fact, I believe that the emphasis on programming is misplaced because a game's design is far more important than how pretty the graphics are, and the game's graphics depend more on the work of visual artists than on some coder who's always trying to bum a few cycles. To be sure, the best programmers can combine with the best game designers and aound and visual artists to produce a game that is enjoyable to play and visually stunning as well as a programmatic masterpiece, but simply being a programmatic masterpiece is not sufficient.
The point is that different developers are trying to accomplish different things. Not every developer will share your vision of the way things ought to be. Those that can produce a commercially viable product will get to do it again.
Sigh. I don't know about you, but this really un-made my day. AMSAT has to be about the bravest amateur experimenter group out there. They envisioned a new day for ham radio powered by a super satellite that would give you worldwide range with a walkie-talkie and a handheld beam.
No offense, but just when did manufacturers start making SSB handhelds? I must have missed the announcement. (You must have missed KA8IFC's article on working through an early RS (RS-8?) with an HT and a 5/8 whip lo these many years ago.)
The fact of the matter is that the "brave new world" would still not have appealed to the people that AMSAT is trying to attract because it makes satellite communications about as interesting as walking up to random people at a mall somewhere. Eliminating the challenge of the operation forces people to focus on the fact that what is being communicated isn't all that interesting or earth-shattering.
I've heard it said that amateur radio is the "national park of the mind" but the people who most often use the phrase don't seem to realize what it means. People don't go backpacking because it's the easiest way to get from one place to another or climb mountains with pitons and rope (or even without) because that's the easiest or even cheapest way to get to the top. No, they do it so that they can feel as if they have accomplished something.
Working 100 "countries" through Oscar-8 was an accomplishment and worthy of comment and congratulations. Working the fellow on Mir (who I happened to meet a few years back--one of the fringe benefits of being a ham in Houston) was an accomplishment. Working 100 countries through Oscar-40, assuming that they can get it to work (I wouldn't hold my breath because your description makes it sound like no one will get any use out of it even if its command receivers and computers are working) will be something that cause people to yawn. And sending an email to a SAREX TNC proves nothing other than that you can afford the equipment.
Please don't think that I'm trying to be down on your hobby, or mine, either. I'm simply trying to point out some things that you don't seem to realize, but which seem to adequately explain the extant facts concerning the decline of amateur radio. No, the ultimate evil isn't Morse code, it's the belief by persons such as yourself that
the goals that appear most desireable to you will appeal most to potential radio amateurs. It simply isn't so. The coolness factor of Phase-IIID has been greatly overestimated.
I used Debian woody for a while, but apt once installed perl-5.6, and it totally screwed up the dpkg config system. I had to go back to Mandrake (though I don't particularly like 7.2). Has anyone else had a problem with the perl 5.6 package? Is it fixed yet?
In order to understand the problem, you have to understand how Debian does (or at least "did") user-specific stuff. For anything where multiple versions were available, and for which end users might want to select which one to actually use, they set up links in/etc/alternatives and then another link in whichever directory is appropriate, usually/usr/bin or/usr/sbin for binaries.
Since there are multiple versions of perl interpreter out there, and since users might want to select between them, perl was done in this way so you might have/usr/bin/perl linked to/etc/alternatives/perl which would then be linked to/usr/bin/perl-5.005 or some such.
Well, the perl5.6 package deleted the link/usr/bin/perl and didn't replace it with anything. Since many of the install scripts use perl, this started breaking stuff during the upgrade that first included perl5.6. It took me a while, but once I noticed that install scripts were failing with "file not found" errors, I took a quick look and was able to verify both that the broken programs were perl scripts and that/usr/bin/perl was nowhere to be found.
So, I immediately created the symbolic link between/usr/bin/perl and/etc/alternatives/perl and re-ran apt, which fixed everything whose install was broken. Problem solved, and no reinstalling.
Since then, it appears that more recent versions of the perl5.6 package copy the actual perl binary into/usr/bin/perl (at least on the computer I use most,/usr/bin/perl and/usr/bin/perl5.6.0 have the same size and MD5 hash) so the problem does appear to have been fixed. However, I'm seeing some wierdness in woody that may be associated with the recent switch to package pools. (From what I understand, package pools allow files to move from "unstable" into "testing" without massive quantities of copying any time someone makes a change. This is a more significant development than a "testing" release, in my opinion.)
Slashdot Mirror
I looked and I looked and I looked, but I couldn't find any way to disable the "crash every couple of hours taking out all changes" option. Neither could I find any way to disable the "lock the application solid every 30 minutes so I have to kill it without saving." option.
I can put up with it drawing funkly red and green lines where it thinks I'm doing the wrong thing. Fact is, like that other fellow, I'd rather complain than set it to not do that. At least that way, the two or three percent of the time that it's pointing out a genuine error, I can get some use out of the feature. However, a word processor that crashes and locks up and loses data randomly is not something I'd wish on my worst enemy.
My preference is to use LyX. The documents that are produced by LyX may not be as pretty (as near as I can tell, the reason that the spec I wrote was converted into "Word" was so we could put the company logo on the title page) but it's the content of the document that's important, isn't it? Besides, LyX has never eaten any of my data and refused to save it when asked.
No category 1 or 2 defects should exist in released software and category 3 defects should only be permitted if the repairs will have a strong negative impact on the schedule. (I have never shipped a product with any but category 4 defects.)
The whole "valid" vs "invalid" inputs may confuse some people, so I should probably explain. I'm used to working in embedded systems where the system reads some measured values. Typically, those values will be represented to the system as a current, a voltage, or a contact closure. The "4 to 20" current loop is typical of the sort of thing I'm talking about. In that sort of system, the physical value is calculated from the current in the loop which varies from 4 mA to 20 mA. If the current is within that range, then the interpretation is easy. The question then becomes what happens if you get 0 mA or 22.5 mA? Neither of those is valid current as far as the system is concerned so it's not clear that the normal conversion to measured value should apply.
However, you will see such values in practice. The first is what happens when the wire gets cut, the second might be the result of an uncalibrated transmitter. A large part of the design of an automated control system has to do with figuring out what to do with those out of range values.
However, other sorts of programs get presented with invalid inputs, so the approach is not without merit in the more typical case. If, for example, you present a COBOL compiler with 6 MB of random data (as an acquaintance of mine once did) it shouldn't crash and should give you some kind of helpful error message. If it did the first, it's a category 1 defect, if it didn't do the second, then it's a category 3 defect.
Do I get to pick the number base I represent the result in?
The first run lasted considerably longer than 8 weeks. I can recall watching "Star Wars" at the Raintree Cinemas during the last week of the first run more than a year after it opened.
Add to that the fact that most every wired telephone, all of the wireless phones, all of the TV's, VCR's, stereos, remote controls, calculators, and so forth have embedded processors in them. It adds up, and quickly.
The only problem I had with the story is the implication that embedded systems are a new thing. When I started doing embedded systems in 1991, most or all of the names that they mentioned as dominating the real-time OS market were already well established. The embedded systems themselves were the very first application envisioned for microprocessors. From my perspective, embedded systems aren't the next thing, they were the first thing. I guess the rest of the world is just now catching up.
Several people have commented on how greedy the stations are who won't pay an air personality triple his salary to stream his program. Don't you think that if there were large profits to be had for those stations that streamed their content that they would pay up? Loudly complain about the cost, certainly, but pay up anyway just to get the extra revenues. Greed can work both sides of this particular street.
Only about three year's worth. It's not like I can go out at drop a grand or two on a video card in the hope that I might be able to make it work, as you apparently can.
sydb also wrote:
So, if I walk into Best Buy, I can ask one of the guys in a blue shirt for a "high-end NVidia card" and they'll hand me a box labelled "high-end NVidia card" and I'll buy it and take it home and be happy? I don't think you read my post.
This is not to mention the fact that, of the three games that I mentioned as owning or being interested in owning, none of them are able to use the NVidia cards, according to the system requirements label on the box.
This is also not to mention that the computers that I own already have 3D accelerated video cards, but only under Windows. It is most uncool to have to boot Windows-NT to play Quake-II, which I've only purchased the Linux version of.
sydb also wrote:
Right. See the above question about "Best Buy". (I didn't see anything resembling an "old 16Mb 3DFX VooDoo 3 based card" either there or at CompUSA. Maybe I should try Fry's. After all, it's the last day of their grand opening today.)
As for the prices on Ebay, well, I looked on Ebay some months back and I attempted to determine that the precise cards being sold had support for 3D acceleration. This is because some VooDoo cards won't work and I don't particularly feel like wasting time and money on solutions that don't work. As near as I could tell, of the inexpensive cards being offered at that time, none were supported under Linux. I already have 3D accelerated hardware that doesn't work under Linux, thank you very much, I don't have to buy any more.
sydb also wrote:
Yes, of course. That's why I installed XFree86 4.0.1 as soon as it was available for Debian Unstable and why I was disappointed that it wouldn't work with the same video adapter that does 3D acceleration just fine under Windows. However, if you want to run one of the three games that I mentioned as owning or being interested in, they say they don't work with XFree86 4.x's 3D acceleration. Again, I'm not interested in pursuing solutions that are documented as not working.
In fact, I'm wondering what you run with your 3D accelerated video under. Nothing that I'm interested in seems to want to use OpenGL. Except for the screen savers, of course, and they work just fine on both the computers I routinely use, even if they are slow as snot.
Who are these "non-comercial[sic] Linux users" that you are talking about? I can't speak for any other Linux user, but I don't mind paying for software. In fact, many Linux users actually do pay for software. This is known because that software is the games that people talk about having to reboot into Windows in order to run.
I can, however, talk about why I don't buy Linux games. So far, I've bought three of them. I've got "Civilization, Call to Power", I've got Quake II, and I've got Quake III. (I can definitely confirm the poor sales of the last. The Half-Price Books near my house has maybe a dozen copies in those cool limited-edition tins.) Of those, the only one I paid full price for was CivCTP. I chose to pay full price for CivCTP in order to support Loki and encourage others to produce games for Linux.
My primary difficulty with the current crop of Linux games is the fascination that those who create those games have with 3-d acceleration. I don't know the incantations needed to get hardware 3-d acceleration under Linux. I haven't yet been able to figure out which card to buy that offers 3-d acceleration under Linux or which software to install to cause it to occur. I go to Web sites like Linux3D.org and I leave more confused than anything else.
In particular, the cards that are on sale down at the local Best Buy don't seem to correspond to anything listed in the compatability list.
So, I've bought these games (and the Half-Price Books has Heavy Gear II for Linux for $14.95, but I haven't purchased it) but I can't play them because they require stuff that I don't have. Maybe if someone ported a game that didn't require hardware 3-d acceleration, it would sell better. I know I'd be more likely to pay full price for it.
There seems to be some confusion.
PM-4's and Maxen and Cisco's AS-5x00 series equipment are all called "Terminal Servers" but they aren't the same things as what Microsoft calls a "Terminal Server". If you had an NT box that just answered the phone and set up PPP sessions with people, you don't have to have a Windows license for everybody that connects.
From the Microsoft perspective, Terminal Servers seem to be computers that run applications that appear on terminals. That's quite a different thing.
Of course, if I'm the one that's confused, you should feel free to ignore this.
People are like people everywhere you go, but sometimes you have to interpret their actions in the context of their society to see that.
It's most likely going nowhere in Texas and the article shows a profound misunderstanding of how Texas politics work, and considerable intolerance. I mean, one legislator proposes one bill out of the thousands that are submitted for considertion before the legislation goes out of session and it's supposed to reveal how all Texans think about all things? Does everyone in your neck of the woods think exactly alike? About all issues?
I guarantee that the background and focus and political bent of a typical person down in the Rio Grande Valley or up near El Paso or deep in the "piney woods" of East Texas are different from the people in more urbanized areas like Houston or Dallas or San Antonio. Even then, 100 people from even from the same area and socioeconomic class will have 100 different political beliefs and backgrounds. That's the way it works in the rest of the United State of America and that's the way it works in Texas, too.
The Texas legislature is only in session for about six months every other year, so you see a burst of all kinds of bills submitted right before the deadline for the session. Most of those bills, including this one, haven't a snowball's chance of passing. Some do manage to pass, but are in a form that, except for the bill number, is completely unrecognizeable as the original bill. If the committee is leary[sic] of the bill, it'll likely die there, possibly to be resurrected in 2003, but I doubt it.
I've used PostgreSQL since it was Postgres95 and each major version seems to get much faster, (as in the same query executes in 1/3 to 1/2 the time.) However, I know nothing about running real benchmarks on database systems, so I can't quantify anything. I can only report my impressions, and I think that PostgreSQL is plenty fast enough for use in just about everything you'd use MySQL for.
I'm known to be biased, so make of that what you will.
You've completely left out the efficiency factor from your calculation. While it is true that IPv6 allows a standard metric buttload of addresses, the system is set up to assign those addresses quite inefficiently.
For example, the standard assignment for an individual end user is likely to be a /64, which has appriximately 16E18 addresses in it, of which only one will be used, typically. Small ISP's like myself are currently assigned a /48, which has enough addresses for 65K end users, of which only a fraction will ever get used.
Of course, should the address space starts to become exhausted, what will happen is what always happens when a nonrenewable resource becomes scarce: conservation, but for right now IPv6 addresses in freaking huge blocks are easy to get. I've got 2^80 addresses, myself.
To answer the question asked in the subject, the reason the blocks are so large is because the routing tables would quickly become huge if the assigned blocks were smaller. That means that ISP's will likely assign blocks to end users and not worry about whether or not those end users assign those addresses to multiple computers. It's more work than it's worth to keep track of those addresses individually. NAT will still be around, though, because people like the additional security offered by it.
Actually, the tax cuts necessarily benefit primarily the people who pay the taxes. People who are poor pay no federal income tax so they cannot possibly benefit from a tax rate reduction. Since people who earn more than $50,000 a year pay essentially all the income taxes in the United States, people who earn more than this, (the population that people like you tend to define as "rich" in order to make the "only the rich will benefit from a tax cut" statement true,) are necessarily going to reap essentially all of the benefits.
Myself, I'm one of those "rich" people who pays my share of those income taxes and probably a goodly chunk of yours, too, and I'd like to point out that it isn't the government's money, it's mine, and I'd like to be permitted to keep a little more of it.
If, as you also say, that nobody with the authority to choose the license understands what you wanted when you proposed to release the code under GPL, then you did not, as you say, "follow the appropriate steps for applying the GPL to the software" which include, as a necessary step, getting the owners to agree with releasing the code under the GPL and understand what that means.
You can't trick someone into accepting the use of the GPL by keeping them ignorant of what that means and so, if you don't have the authority to make that decision yourself, you have to make the persons in authority aware of the ramifications of that choice. If I were in that situation, I'd apologize profusely for overstepping my authority and put together a document directed toward the decision-makers explaining the benefits of releasing the source under the GPL.
Further, I'd avoid lengthy discussions on the putative benefits to society for using the GPL and focus on things like potentially spreading the support burden over a larger customer base. Maintaining home-grown software is expensive and you might be able to justify that choice of licenses based simply on that. That's more likely to go over well with people who don't view this as a moral issue.
Actually, the USA inherited that idea from the British who stole the idea from the Dutch. It has nothing to do with getting around the US Constitution and everything to do with sharing the financial risk of paying for a manufacturing business. I'm not aware of any country in the world that doesn't have corporations, which is what you describe when you talk about giving a company the legal status of a person. Certainly, all of the North American countries have corporations as do all of the European Common Market countries.
The people who came up with glibc-compat did so because they anticipated the difficulties associated with upgrading the systems as a whole to newer libraries. There's nothing wrong with installing the older libraries and they're not something that should be avoided for "production" systems.
To be sure, it would be nice if Oracle got with the program and updated their tools to run on a more recent glibc, but until that happens, you have an alternative to sitting around, scratching your head, and saying "Gee, it doesn't work." That makes more sense than the "you should statically link all major applications" crud that others have posted.
Ummm, no. Or, at least, not necessarily. There are substantial diseconomies of scale associated with business, and in a service business like the ISP business, there are few or none of the economies of scale that are associated with manufacturing businesses.
For example, the total tech support payroll at the small mom-and-pop (I'm the "pop") ISP that I own is smaller than SWBell's payroll for tech support managers. Those tech support managers don't provide tech support, but they do add to the cost of providing tech support. Therefore, tech support is easier to afford for the smaller ISP than for a company like SBIS.
Of course, the razor thin margins are there and cause failures, but the companies that tend to fail are those that borrowed a bunch of money, (or sold a bunch of stock,) often to buy up smaller companies, and have discovered that they can't make enough beyond their overhead to make the interest payments. In this case, the small ISP's are the ones being bought, not the ones doing failing
Anyway, two things have been obvious to me for some time. First, providing access to the Internet to individuals is not going to be a license to print money, like people were thinking it was going to be five years ago. As you say, the barriers to entry are too low for that to happen. So, the successful ISP will need to focus on other areas to make most of their profits. What Brokersys tries to do is to have the dial-up stuff to pay for its share of the fixed cost, but we make most of our profits on other things. Second, many people will pay a premium to buy their Internet from a smaller company. It is, therefore, a mistake for a small ISP to try to price themselves like the big discounters.
You know, someone who was used to working with medium-sized C programs and who wanted to tweak the virtual memory code would probably just cd to /usr/src/linux/mm (where I simply guessed that "mm" stood for "memory management") and start there. The Linux kernel is organized fairly well and is no worse documented than most of the source I've inherited over the last 10 years of embedded-systems programming that I've done. However, you do have to be prepared to do some detective work on your own.
Just about any large project is going to be, as you put it, a "zoo" because it is tough to write large programs. Programmers that expect to spend any time at all working with other people's source are going to anticipate this and develop a toolkit to deal with it and, although it is difficult to become familiar enough with a source set to find your way around it without trouble, the more experience you have with the source set, the easier it is.
My own personal belief is that the desire to not redesign is far more powerful and needs to be guarded against far more than the desire to redesign. However, you need to keep backup copies of everything in case you make a mess of things. I've never understood why some programmers just start making changes to their source without making sure they can get back to where they started.
As for selling it to your superiors, well, if you're the programmer, it's properly your decision, not theirs. You don't ask them for permission to do it, you tell them that this is what needs to be done, or maybe you tell them that this is what you did. You're the only one who is in a position to tell whether the least effort approach is to fix or replace, so act like it.
Sure, it's usually a good idea to consult with people of differing perspective and varying experience before taking any drastic action, and you must consult with the other programmers any time your changes might affect what those other programmers are doing, but if you're the programmer, you should have the final say in how the programming goes.
If you can't make that stick, and I haven't always been able to, you can always use your coffee break time, lunch hours, the odd evenings, and sometimes weekends to do your rewrite or redesign as a kind of a "skunk works" project. I've done that a time or two, but you must guard your time off jealously. If they already expect you to work evenings and weekends, then it's probably best to put your CV out. In this job market, there are other places to work.
Not universally. Italy, for example, didn't spend 1% of what the USA did on testing or fixing the "Y2K" problem and they are every bit as computerized as the USA and had the same level of problems.
You don't think the fact that most time-dependant programs generally make the assumption that the clock isn't going to make large jumps either forward or back could possibly have contributed to those failed tests, do you? The fact that there were more problems attributed to the Y2K testing than to the actual event indicates to me that most of the effort to "test" for "Y2K compliance" was not just wasted, but actually harmful. (In fact, I got bit more badly by a misguided Y2K test than by the sole Y2K bug that hit me.)
There are two things to learn from Y2K. First, you can't test the time-dependance of software by simply resetting the clock. To properly perform the test, the state of the machine has to be updated to match what it will be when the date in question actually arrives, not the state it happens to be now. That is difficult and is not usually easily accomplished. Setting the clock back is even harder.
Second, there are classes of bugs and not all are harmful. The errors that were actually seen (of which various Perl scripts printing 19100 for the year starting January 1, are a prime example) were exactly what I believe we'd have seen more of if all the hype hadn't happened. I expect that if you put the power plant control software from two years ago into the plant's computers now there would be absolutely no change in it's operation because control software typically doesn't know or particularly care about what the date is.
Please note that those countries and companies that spent very little on "Y2K compliance" had about as many problems as the USA and Canada and those banks and airlines that went through all the nonsense. If it had such a potential for disaster, shouldn't we have seen at least one life-threatening failure somewhere? Perfection is difficult to achieve in practice and so saying "it would have been a disaster, but for the efforts of those raising the alarm" because we've apparently somehow achieved perfect Y2K compliance is a bit hard for me to believe, especially in light of the disastrously ignorant way many organizations approached their Y2K testing.
In short, I believe that the world wouldn't have ended or even been inconvenienced even if all the consultants hadn't existed and none of the hype had occured. I'm sorry that it hurts the feelings of one of those consultants for that to be a common view, but I don't believe that it's an unreasonable view and my sympathy is tempered by the amount of hassle and extra work I had to go through because people like Peter de Jager and Ed Yourdon spent the last decade whipping people up into a unreasoning frenzy so they could make twice my income selling technical armageddon seminars to the PHB's.
You have selective memory. Some games have always pushed the hardware to its limits, but the reason that PC's had "turbo" buttons for years was because most games, and turbo buttons were all about games, did not push the hardware and you had to slow a faster than standard computer down for them to be even near playable. Most console games even then didn't come anywhere near taxing the hardware they ran on. Some (and here I'm thinking things like Atari chess) did, but it was less about graphical displays than it was about limitations of RAM and ROM. The graphics were intended to be competitive with the often specially-designed arcade equipment and, for the most part, achieved that easily by including similar hardware.
Carrion also wrote:
And how many other game programmers, all of whom are writing games that require substantial upgrades to the typical Windows computer just to run, are driving Ferraris? Damn few. Isn't it just possible that, given the success that some people have while writing games that push the hardware when others fail utterly, even though they push the hardware every bit as hard, that the success doesn't really have that much to do with how extreme their performance is?
For what it's worth, I think Id's commercial success has more to do with having a coherent and enjoyable vision and wise business practices than it does with advancing the state of the art in graphical displays. The pushing of the hardware to new performance levels was a side-effect required because the older techniques weren't able to support the vision. But the vision came first.
There is no doubt in my mind that Id's vision is always going to take the hardware to its limits, but that's the sort of games they design. Other designs are not nearly so hardware intensive. (How many megapixels/sec do you need to do a "Tetris", anyway? I would expect that more people play "Tetris" and "Mahjongg" daily than have ever played "Doom", "Quake", or even "Wolfenstein 3-d".) The fact that other sorts of games can be every bit as enjoyable to play and not tax the hardware proves my point.
Carrion also wrote:
Not necessarily, but making a game that uses hardware "to the max" does not necessarily make a game that is a money-maker. It's the emphasis on technically duplicating "Quake" without really understanding what makes "Quake" playable that makes for money-losers. Your counterexamples don't disprove my opinion because they are so rare.
Carrion also wrote:
How do you know? Are you a game artist? I am willing to stipulate that that is what the visual artist might want, but what does the game designer want? I'm not talking about some crap derivative game designer who is trying to duplicate "Quake" or "Half-Life" or "Diablo" because he thinks, as you apparently do, that simply duplicating someone else's success will get you a Ferrari, too. No, I'm talking about someone who has a different idea of what people will play.
You can't tell me, because you can't imagine such a person.
Perhaps one that had a game with good gameplay but not so flashy graphics who wanted to sell to as wide a market as possible? Many people believe that this thing that you also wrote:
Is so wrong that it's not even funny. Game programming is about producing an enjoyable game, not about throwing megapixels on the screen. The whole "pushing the hardware to the very limit" BS is a fairly recent phenomenon, and may be the reason that PC games (not just the Linux ones as reported on /., but PC games in general) typically are money-losers.
In fact, I believe that the emphasis on programming is misplaced because a game's design is far more important than how pretty the graphics are, and the game's graphics depend more on the work of visual artists than on some coder who's always trying to bum a few cycles. To be sure, the best programmers can combine with the best game designers and aound and visual artists to produce a game that is enjoyable to play and visually stunning as well as a programmatic masterpiece, but simply being a programmatic masterpiece is not sufficient.
The point is that different developers are trying to accomplish different things. Not every developer will share your vision of the way things ought to be. Those that can produce a commercially viable product will get to do it again.
No offense, but just when did manufacturers start making SSB handhelds? I must have missed the announcement. (You must have missed KA8IFC's article on working through an early RS (RS-8?) with an HT and a 5/8 whip lo these many years ago.)
The fact of the matter is that the "brave new world" would still not have appealed to the people that AMSAT is trying to attract because it makes satellite communications about as interesting as walking up to random people at a mall somewhere. Eliminating the challenge of the operation forces people to focus on the fact that what is being communicated isn't all that interesting or earth-shattering.
I've heard it said that amateur radio is the "national park of the mind" but the people who most often use the phrase don't seem to realize what it means. People don't go backpacking because it's the easiest way to get from one place to another or climb mountains with pitons and rope (or even without) because that's the easiest or even cheapest way to get to the top. No, they do it so that they can feel as if they have accomplished something.
Working 100 "countries" through Oscar-8 was an accomplishment and worthy of comment and congratulations. Working the fellow on Mir (who I happened to meet a few years back--one of the fringe benefits of being a ham in Houston) was an accomplishment. Working 100 countries through Oscar-40, assuming that they can get it to work (I wouldn't hold my breath because your description makes it sound like no one will get any use out of it even if its command receivers and computers are working) will be something that cause people to yawn. And sending an email to a SAREX TNC proves nothing other than that you can afford the equipment.
Please don't think that I'm trying to be down on your hobby, or mine, either. I'm simply trying to point out some things that you don't seem to realize, but which seem to adequately explain the extant facts concerning the decline of amateur radio. No, the ultimate evil isn't Morse code, it's the belief by persons such as yourself that the goals that appear most desireable to you will appeal most to potential radio amateurs. It simply isn't so. The coolness factor of Phase-IIID has been greatly overestimated.
In order to understand the problem, you have to understand how Debian does (or at least "did") user-specific stuff. For anything where multiple versions were available, and for which end users might want to select which one to actually use, they set up links in /etc/alternatives and then another link in whichever directory is appropriate, usually /usr/bin or /usr/sbin for binaries.
Since there are multiple versions of perl interpreter out there, and since users might want to select between them, perl was done in this way so you might have /usr/bin/perl linked to /etc/alternatives/perl which would then be linked to /usr/bin/perl-5.005 or some such.
Well, the perl5.6 package deleted the link /usr/bin/perl and didn't replace it with anything. Since many of the install scripts use perl, this started breaking stuff during the upgrade that first included perl5.6. It took me a while, but once I noticed that install scripts were failing with "file not found" errors, I took a quick look and was able to verify both that the broken programs were perl scripts and that /usr/bin/perl was nowhere to be found.
So, I immediately created the symbolic link between /usr/bin/perl and /etc/alternatives/perl and re-ran apt, which fixed everything whose install was broken. Problem solved, and no reinstalling.
Since then, it appears that more recent versions of the perl5.6 package copy the actual perl binary into /usr/bin/perl (at least on the computer I use most, /usr/bin/perl and /usr/bin/perl5.6.0 have the same size and MD5 hash) so the problem does appear to have been fixed. However, I'm seeing some wierdness in woody that may be associated with the recent switch to package pools. (From what I understand, package pools allow files to move from "unstable" into "testing" without massive quantities of copying any time someone makes a change. This is a more significant development than a "testing" release, in my opinion.)