Anyone who's interested in even minor changes that could improve Enterprise should visit First TV Drama. The guy gives a very good analysis of what is wrong (and sometimes right) about each episode.
You are correct, though -- not having to satisfy any cross-range requirements in your design does mean you can control where the heat goes more easily; but overall heat loading remains about the same.
Isn't thermodynamics wonderful? Yep, you get the same amount of heat no matter how fast or slow you descend. The primary thing that changes is how fast you can dissipate that heat. If a large buildup is allowed, your craft will become a crispy critter in no time flat.:-)
ANYTHING except this nonsense about history needing a DUMBASS. I mean really! Archer goes around, screwing up everything in his path, gets all "in-your-face" pissy over his stupid DOG, then somehow is a requirement to the founding of the FEDERATION? God! No wonder we haven't heard about Archer before! Everyone tried to forget the fact that HISTORY NEEDS A DUMBASS.
AoA doesn't really come into it much. Once you enter the atmosphere, you're losing huge amounts of velocity. At hypersonic velocities, L/D ratios are awful, pretty much no matter what your AoA is.
It depends. Obviously, the atmosphere is much thinner the higher up you go. The sooner you can obtain a flight envelope (rather than the "falling refrigerator" configuration of the shuttle), the longer you can take in your descent. Keep in mind that the Space Shuttle intentionally bleeds off a lot of speed by doing a supersonic slalom on the way down. This is such a difficult flight path, that only one human has ever flown reentry on manual. All other flights were handled by the computer. There's a nice description of reentry here.
At least two designs other than the shuttle's current one were considered:
On faster descent:
Despite these arguments that eventually prevailed, at least one straight-wing design was prominent for a time, in part because of its designer. Max Faget, the chief engineer at NASA's Manned Spacecraft Center (later renamed the Johnson Space Center), drew up plans for two straight-winged vehicles--one an orbiter and the other a booster stage--that rode piggyback and were both piloted and fully reusable. [snip] Faget argued that his design would enable the orbiter to return to Earth at a sharp angle that would significantly heat only the orbiter's lower surfaces (Faget, pp. 52-54)
On slower descent:
If it weren't for the payload bay requirement, a lifting body configuration might have worked well. Lifting bodies could have been a good compromise between ballistic capsules and delta- or straight-winged vehicles. They are lighter, have simpler structures, and encounter fewer reentry heating problems than winged vehicles. Lifting bodies have better lift-to-drag ratios than ballistic capsules, which enables them to be piloted more accurately (Peebles, December 1979, p. 487). Lifting bodies had even been considered for the Apollo command modules (Peebles, November 1979, p. 439). Throughout the 1960s and early 1970s, NASA and the Air Force had conducted significant research on various lifting body programs such as the X-23A and the X-24A, demonstrating, among other characteristics, the maneuverability of wingless vehicles (Reed, pp. 129--131, 140).
I don't have a link at the moment, but descent was a big problem in the early rocket plane experiments. If they descended too slowly, they'd lose their flight envelope and become difficult to control. But if they descended too quickly, the craft would heat up at an incredible rate.
Actually, there is in fact a way to be in a stable balance of inertial and gravitational forces by thrusting straight up; just hit one of the lagrange points
Except that you'd have to thrust 930,000 miles before you hit the L1 point (the closest). I think that's a bit more than the 200-1000 miles that current space craft have reached. Not to mention that orbital velocity allows you to "steal" energy from the earth via a slingshot effect, thus allowing you to thrust just about anywhere with orders of magnitude less fuel.
Does this link help? NASA is surprisingly honest on what went right and what went wrong with the program. The one thing they don't cover is that it was Nixon's decision to scale back the space program and merge it with the Air Force. After we reached the moon, Nixon decided that having a low cost "token" space program would be enough.
The truly amazing part is the work that the engineers did. They were given a set of impossible requirements that were all at odds with one another, and the engineers still managed to develop a craft that met the specs. In almost all ways, the Shuttle problems were political, not technical.
There's some info on the Air Force's desires for the Shuttle on NASA's History Site. From the article:
One Air Force requirement that had a critical effect on the Shuttle design was cross range capability. The military wanted to be able to send a Shuttle on an orbit around the Earth's poles because a significant portion of the Soviet Union was at high latitudes near the Arctic Circle. The idea was to be able to deploy a reconnaissance satellite, retrieve an errant spacecraft, or even capture an enemy satellite, and then have the Shuttle return to its launch site after only one orbit to escape Soviet detection. Because the Earth rotates on its axis, by the time the Shuttle would return to its base, the base would have "moved" approximately 1,100 miles to the east. Thus the Shuttle needed to be able to maneuver that distance "sideways" upon reentering the atmosphere.
Given a choice between straight and delta wings, the latter perform much better in terms of cross range capability. Delta wings produce more lift at hypersonic speeds, enabling more maneuverability (Heppenheimer, p. 220). Given the requirement for cross range capability, a delta-winged vehicle became the clear choice. Additionally, delta-winged vehicles do not heat up as much as straight-winged vehicles during atmospheric reentry (Draper et al., p. 26), thus decreasing the need for expensive and potentially heavy thermal protection systems, although the thermodynamics are too complex to cover fully in this paper. Moreover, some aerodynamicists argued that delta-winged vehicles were a proven technology that provided good balance, stability, and aerodynamic control (Draper et al., pp. 29, 35).
Now you know why the Space Shuttle has stubby delta-wings for hypersonic flight. I'll see if I can dig up some other links.
Is that kind of how humans learn how to fly. You just fall and miss the ground???
Believe it or not, I just used that gag to explain orbital velocity to a coworker. (Everyone here saw Melvill on CNN.) It got a few chuckles, anyway.:-)
Red Faction for the NG was a big pile of suck. It was like RoTT, but with far worse graphics, no handling, and impossibly shitty graphics.
Rise of the Triad? Oooo... now there's an insult if I've ever heard one.
The N-Gage has no business running 3D games.
I can't say I disagree. Good 3D requires a hellva lot more than pushing a few polygons. At the very least, you'd need a bigger screen for a better FOV. And programming for a dinky 104MHz ARM? Reminds me of the days of RayCasters and home brew 3D engines. Ah, the memories.
Sadly, the best parts of the N-Gage were removed from the QD. I listen to the radio a lot on mine, and use it for a lot of MP3s and other media (especially since I can't sync my iPod what with the sbp2 layer being broken in Linux 2.6).
Do you really use it for Games that much, or do you like the N-Gage primarily for it's other features? If you just like an occasional Java game, then the Nokia 6800 series might be a better choice. Color screen, built-in radio, J2ME support, AND it flips open to reveal a full keyboard and joystick.
It gets worse: currently they're hardly addressing *the* most difficult concept for cheap reusable spacecraft: reentry. This single problem has contributed to the majority of the space shuttle's turnaround cost.
Arguably, the Space Shuttle's design is so poor because the Air Force wanted a relatively low altitude fly-by over Russian soil. Had the Space Shuttle been designed to Aero-brake much slower, it could have forgone the disposable heat shields. However, there is some question as to the difficulty in obtaining a proper flight envelope when entering the atmosphere at that shallow of an AOA.
Yes, but couldn't they just go higher and fall into orbit?
Attaining orbit is not a matter of height. It's a matter of going so fast that you continuously miss the Earth. The only reason why a space craft has to fly so high is that the thick atmosphere will slow it down.
There is also no 3D GPU -- it's all software rendering based around its main CPU, which is why it takes 144Mhz to do anything close to a PS1 level of graphics.
Yeah, I realized that after posting. It's a 104 MHz ARM processor that does both 2D and 3D. Granted, that's more power than my 486 had back when I was running Doom, MechWarrior, and Wing Commander 3, but it seems like it wouldn't quite be enough to port something like Red Faction. I'm guessing they take the old "cheat like hell" route.;-)
but there is absolutely no IR support on the N-Gage
Oops, seems you're right. I misinterpreted a specs page as a "list of features" rather than a "checklist of features". IR had a red X next to it.
Linux was one hell of a lot piss poor than BSD at that point in time regardless of the couple of kilobytes that were removed from the BSD codebase. Before the 2.4.x kernels, only a GNU bigot would bother using Linux for anything.
Dude, you need to go MUCH farther back in time. When Linux came out, you needed a MINIMUM of a 286 AT machine to run BSD. Minix ran on an 8086. Linux attempted to copy the small footprint of Minix instead of the large footprint of BSD.
The reason for BSD's poor performance was that it was originally written for Mini-Computers (a serious step up from Micro-Computers) like VAXes and PDPs. PCs of the era lacked many of the computing features that made BSD and Unix possible. As a result, OSes had to simulate those features in software at a cost of CPU and memory.
Once PCs reached the stage of 386s, they were finally able to run Unixes without issue. Given BSD's 10+ years of development, it was obviously more advanced than Linux. It also helped that BSD was were all the "modern Unix technology" was developed. (e.g. TCP/IP, Fast File System, strong Multiuser support, etc.)
At the time Linux was being created, they had released an incomplete version of the system (Net Release 2) minus the AT&T source code that was still in the system.
You forget that Minix wasn't free either. BSD was an option, it was just a piss poor one.
They didn't design it like you suggested because you have more clue than Nokia
While that's an easy stance to take, I feel I should point out that the 6800 series of phones are also built by Nokia. Therefore someone in Nokia must have a clue, it just doesn't appear to be the ones who designed the N-Gage.
Perhaps the real problem with the N-GAGE form factor is that Nokia tried to pack too much stuff into it. The N-GAGE does games, Java, MP3s, Radio, Bluetooth, IR, and a bunch of other junk all while trying to be a phone. At the very least, the standard battery simply wouldn't be powerful enough for more than a half-hour of game time. A single game could result in serious draw by the following devices:
- Main CPU - Bluetooth processor - 3D GPU - FM Digital Signal Processor - LCD Color Display - Standby GSM communications
Between all of those, I wouldn't be surprised if the power draw was somewhere around 3-10 Watts! ("Standby" power draw of a phone is usually less than a Watt.) You'd need a Laptop battery to power the thing for any appreciable amount of time. If Nokia had simply scaled back the device in a few areas, they might have had a good shot at a first gen device. Instead they overengineered it and guaranteed failure.
BTW, I think I know why you have to remove the battery to change the game. The Nokia engineers were probably stumped by the issue of making the user reboot the handheld before changing the cartrige. Game systems like the NES and Gameboy would actually lock the cartrige when they were turned on. Nokia's solution was to instead force people to remove the battery. This guarantees that the phone will be shut off when the cartriges are swapped and circumvents the requirement for a mechanical switch to lock the cartrige. It was still a dumb idea.
Err, the problem with Janeway wasn't that she was a non-jerkoff-material woman, but that her character was not convincing.
Indeed. If they'd made her more like Rachael Garret, THEN we'd have a captain to be proud of. Instead, we got Janeway who got all blurry-eyed at the slightest little thing Kes did. Oh, and her biggest moral dillema was whether or not to treat the Doctor like a Real Boy^H^H^H Person.
Inform me if I'm wrong, but didn't Linus make Linux because he didn't like Minix?
Not exactly. Minix was pretty much the only option other than BSD at the time, and BSD required some beefy hardware. The problem was that Tanenbaum didn't want to add the features necessary to make Minix a useful OS. He wanted it to be a teaching tool. The result was that Linus used Minix to bootstrap Linux development to fill the vacuum.
What I don't get is why Nokia didn't design it like the 6810. The 6810 even has a joystick! Just replace that keyboard with a DPad and buttons, and you'd be in business. Instead they thought that everyone would want to talk into something that looked like a reject from a Fischer Price factory. Go figure.
Except it's a lot easier to eat a few crackers than to undergo surgery to replace a battery.
You know, they used to use Plutonium to prevent this sort of problem. It was only after the whole Chernobyl scare that companies stopped producing pacemakers with long-life power sources. Sometimes I wonder how much of our technological "progression" is nothing more than an illusion.
Or maybe we just haven't learned yet to only use computers for the things they're good at and to drop the hype about them being good for everything in life.
I'm not sure I agree. It's hard to deny that computers *have* effected a change in business to the degree where the work of dozens of workers has been condensed into one person. Part of this can be attributed to programs like word processors and spreadsheets. Where a secretary and an accountant used to be a requirement for simple tasks, these tasks can now be accomplished without their assistance. Yet that doesn't explain web applications. How do web apps help? Do they even help at all?
The answer is truly a thing of beauty for businesses. Instead of paying a small army of typists and filers to keep the information organized, processed, and up to date, a web app allows a company to push the data entry to the customer. (Note that the customer feels this is a "feature".) And since the information is already is a computational device, it can be processed with little to no human interaction. So yes, computers are good at many things. The core of the problem is having someone who knows how to use them correctly.
PDA's are great, but a pencil and paper always beats every one of them for speed.
Depends on what you're doing. My wife is able to keep track of our checking account much more efficiently with her Palm Pilot. Ditto on her shopping list. It's also good for downloading and displaying recipes, and reading ebooks. It's NOT good at taking quick notes, or writing your next novel. And it definitely is not good at creating spreadsheets, surfing the web, listening to MP3s, or doing a zillion other things that people seem to think Palms should do.
Disks and filesystems are great, but an organized secretary with a well-laid-out file drawer will kick the PC's ass in knowledge about how all the information fits together, albeit she'll lose from a portability standpoint.
Agreed. But why can't she keep track of those same files in electronic form? That way she can make infinite copies at a whim, instantly transmit critical data anywhere in the world, and pull any file without leaving her desk. Project Managers and Business Analysts have long had to organize files for easy access. It's just that some are better than others. It might not be such a bad idea to make all filings run through a secretary rather than an open file server. Alternatively, the use of a meta-data file system can give many of the same advantages. If you tag each file with things like project, client, creator, etc., you'll develop many of the same indices that a filing secretary would.
And yet, what is the big money stuff in computers? Customer Relationship Management software.
Databases are generally A Good Thing(TM) as they allow for various computations to be done on that data. (Data Analysis is simply another form of computations.) Most CRM software sucks because it really ISN'T a database. It's really nothing more than a glorified (and confused) filing system. Put the data in a damn mainframe or SQL database and you'll find that you can generate much more useful reports.
We're another five to seven years from realizing that computers just simply don't do certain things well and they never will. It won't be an ephiphany or a sudden realiziation of these facts, people will just slowly migrate away from computers in areas they don't work well in, over time.
I don't think it's that easy. Generally, people want technology to move forward and are unwilling to back up and find a different path. What I do think is that the demand for software will decline, and users will come to the general realization that all they really need is some fairly basic boring application rather than the Gee-Whiz, Got-Pretty-Graphics-and-Features software of today. Software is simply too complex and is overdue for a simplification.
I don't have a problem with testing... because there's frankly no feasible substitute. An objective measure of knowledge has value if sufficiently rigorous. It definitely has value in medicine... but having never taken any sort of computer cert, I can't say whether that's the case for IT or not.
I think the problem in IT/IS/CompSci is that every developer has to be more like a Medical Researcher than a Doctor. In theory, a Doctor can do quite well with just "book-smarts" that tell him what to do in a given situation. And given how little is actually *well* understood about the human body, that's about all a Doctor can be expected to do. Obviously, a good Doctor will develop an intuition through experience, but most of what he does is still based on what the medical researchers tell him works.
In software development, we need less of "do this because it works" and more intuitive understanding of systems. To be really excellent you need to know both how the system works and what you don't know. You have to be willing to research the best way to get from point A to point B while juggling the various factors of cost, complexity, performance, and maintainability. No books or schoolwork can prepare you for this. It's simply something you can or can't do.
Unsurprisingly, a tremendous number of CompSci researchers and developers have spent decades trying to make this not the case. They've gone through 4th generation languages, GUI Builders, code generators, componentization, scripting, etc. all in hopes of finding a way to allow an average worker to produce excellent results. Sadly, every last attempt has failed. The problem appears to be that all of the "simplified" concepts are based on abstractions that simply aren't good enough. Once they hit the real world, project requirements cause the abstration to break down. This in turn requires that an experienced developer be able to understand what the system is doing from the bottom up. This then leads him back to the same issue of building the system to meet the needs of cost, complexity, performance, and maintanability.
Computer Scientists continue to hope for that "perfect abstraction", but it seems that it will never arrive. Perhaps the only leap forward will be when AI reaches a stage to where it can develop the work for you. But to reach that stage, we need orders of magnatude more computing power than we have today. Not to mention that our mathematical models for solving problems will have to get that much better, and that much more complex.
Maybe, just maybe, the computer as we know it today is an inherently flawed concept? At its core, it really is nothing more than a computational device. i.e. It does math very well. But what we ask it to do today has almost nothing to do with math. We simply push around data to achieve results that appear to be digital representations of physical things. Yet the real world is analog. Do we need an analog "brain" rather than a digital computer?
I personally think that more employers should give a short test as part of the interview, this way they can be fairly confident that the person they are hiring actually knows how to do the job.
I actually did something similar when I was recently interviewing junior programmer candidates. When I noticed that they had "Masters Degree" written all over their resume, I decided to put them through the wringer and ask about various data structures and search algorithms. (Note: I never got a degree myself. Too busy actually performing the job.) I usually started with something complex like Hashtables, then went progressively simpler to Binary Searches, B-Trees, and Linked Lists. Oddly enough, no one knew how hashtables worked. One guy stuttered through so badly that he barely even managed to explain linked lists (and I wasn't tremendously happy with his explanation). The guy I ended up recommending was the one who simply said "I don't know" to the ones he didn't know, and gave detailed explanations of the ones he did know.
Of course, none of this would tell me if the guy could write *good* software. But at least I'd know that he had the basics and could be taught. If it had been a more senior position, I would have taken great care in attempting to find public examples of their work, and spend time chatting to ascertain how passionate they actually are about technology. Sadly, I can't say that I've interviewed a single person who has actually wowed me.:-( It's especially amusing when one considers that I converse with these people online quite often, but never meet one in real life. (The ones I know online are never where I am at the moment.) We must be extremely rare.
BTW, if you're looking for the type of API I'd demonstrate to a tech interviewer, look no farther than my GAGE gaming APIs. The API is clean, the code is simple, and the algorithms are original and unmatched. If I saw something similar out of a candidate, I would go throttle my manager until he was hired. Too bad that pretty much all senior candidates I've dealt with don't even have code to show.
The programmer and time are not fungible. We cannot simple expect to complete a project that takes 1 man 18 months with 18 men in 1 month. As you add more men the time improvements become less and less.
In other words, programmers tend to run afoul of Amdahl's Law.;-)
Actually, Amdahl's Law would probably be a good way of calculating the maximum effective team size. Unfortunately, it can be very difficult to ascertain a value for the "work" needed on a project. Not to mention the "human factor" of programmers who are faster, less experienced programmers, and "cowboy coders" who refuse to check any of their work into version control.
Slashdot Mirror
Hmm... maybe I should have toned that down a bit.
Anyone who's interested in even minor changes that could improve Enterprise should visit First TV Drama. The guy gives a very good analysis of what is wrong (and sometimes right) about each episode.
You are correct, though -- not having to satisfy any cross-range requirements in your design does mean you can control where the heat goes more easily; but overall heat loading remains about the same.
:-)
Isn't thermodynamics wonderful? Yep, you get the same amount of heat no matter how fast or slow you descend. The primary thing that changes is how fast you can dissipate that heat. If a large buildup is allowed, your craft will become a crispy critter in no time flat.
ANYTHING except this nonsense about history needing a DUMBASS. I mean really! Archer goes around, screwing up everything in his path, gets all "in-your-face" pissy over his stupid DOG, then somehow is a requirement to the founding of the FEDERATION? God! No wonder we haven't heard about Archer before! Everyone tried to forget the fact that HISTORY NEEDS A DUMBASS.
Thanks for your corrections.
AoA doesn't really come into it much. Once you enter the atmosphere, you're losing huge amounts of velocity. At hypersonic velocities, L/D ratios are awful, pretty much no matter what your AoA is.
It depends. Obviously, the atmosphere is much thinner the higher up you go. The sooner you can obtain a flight envelope (rather than the "falling refrigerator" configuration of the shuttle), the longer you can take in your descent. Keep in mind that the Space Shuttle intentionally bleeds off a lot of speed by doing a supersonic slalom on the way down. This is such a difficult flight path, that only one human has ever flown reentry on manual. All other flights were handled by the computer. There's a nice description of reentry here.
At least two designs other than the shuttle's current one were considered:
On faster descent:
Despite these arguments that eventually prevailed, at least one straight-wing design was prominent for a time, in part because of its designer. Max Faget, the chief engineer at NASA's Manned Spacecraft Center (later renamed the Johnson Space Center), drew up plans for two straight-winged vehicles--one an orbiter and the other a booster stage--that rode piggyback and were both piloted and fully reusable. [snip] Faget argued that his design would enable the orbiter to return to Earth at a sharp angle that would significantly heat only the orbiter's lower surfaces (Faget, pp. 52-54)
On slower descent:
If it weren't for the payload bay requirement, a lifting body configuration might have worked well. Lifting bodies could have been a good compromise between ballistic capsules and delta- or straight-winged vehicles. They are lighter, have simpler structures, and encounter fewer reentry heating problems than winged vehicles. Lifting bodies have better lift-to-drag ratios than ballistic capsules, which enables them to be piloted more accurately (Peebles, December 1979, p. 487). Lifting bodies had even been considered for the Apollo command modules (Peebles, November 1979, p. 439). Throughout the 1960s and early 1970s, NASA and the Air Force had conducted significant research on various lifting body programs such as the X-23A and the X-24A, demonstrating, among other characteristics, the maneuverability of wingless vehicles (Reed, pp. 129--131, 140).
Source
I don't have a link at the moment, but descent was a big problem in the early rocket plane experiments. If they descended too slowly, they'd lose their flight envelope and become difficult to control. But if they descended too quickly, the craft would heat up at an incredible rate.
Actually, there is in fact a way to be in a stable balance of inertial and gravitational forces by thrusting straight up; just hit one of the lagrange points
Except that you'd have to thrust 930,000 miles before you hit the L1 point (the closest). I think that's a bit more than the 200-1000 miles that current space craft have reached. Not to mention that orbital velocity allows you to "steal" energy from the earth via a slingshot effect, thus allowing you to thrust just about anywhere with orders of magnitude less fuel.
Does this link help? NASA is surprisingly honest on what went right and what went wrong with the program. The one thing they don't cover is that it was Nixon's decision to scale back the space program and merge it with the Air Force. After we reached the moon, Nixon decided that having a low cost "token" space program would be enough.
The truly amazing part is the work that the engineers did. They were given a set of impossible requirements that were all at odds with one another, and the engineers still managed to develop a craft that met the specs. In almost all ways, the Shuttle problems were political, not technical.
There's some info on the Air Force's desires for the Shuttle on NASA's History Site. From the article:
One Air Force requirement that had a critical effect on the Shuttle design was cross range capability. The military wanted to be able to send a Shuttle on an orbit around the Earth's poles because a significant portion of the Soviet Union was at high latitudes near the Arctic Circle. The idea was to be able to deploy a reconnaissance satellite, retrieve an errant spacecraft, or even capture an enemy satellite, and then have the Shuttle return to its launch site after only one orbit to escape Soviet detection. Because the Earth rotates on its axis, by the time the Shuttle would return to its base, the base would have "moved" approximately 1,100 miles to the east. Thus the Shuttle needed to be able to maneuver that distance "sideways" upon reentering the atmosphere.
Given a choice between straight and delta wings, the latter perform much better in terms of cross range capability. Delta wings produce more lift at hypersonic speeds, enabling more maneuverability (Heppenheimer, p. 220). Given the requirement for cross range capability, a delta-winged vehicle became the clear choice. Additionally, delta-winged vehicles do not heat up as much as straight-winged vehicles during atmospheric reentry (Draper et al., p. 26), thus decreasing the need for expensive and potentially heavy thermal protection systems, although the thermodynamics are too complex to cover fully in this paper. Moreover, some aerodynamicists argued that delta-winged vehicles were a proven technology that provided good balance, stability, and aerodynamic control (Draper et al., pp. 29, 35).
Now you know why the Space Shuttle has stubby delta-wings for hypersonic flight. I'll see if I can dig up some other links.
Is that kind of how humans learn how to fly. You just fall and miss the ground???
:-)
Believe it or not, I just used that gag to explain orbital velocity to a coworker. (Everyone here saw Melvill on CNN.) It got a few chuckles, anyway.
Red Faction for the NG was a big pile of suck. It was like RoTT, but with far worse graphics, no handling, and impossibly shitty graphics.
Rise of the Triad? Oooo... now there's an insult if I've ever heard one.
The N-Gage has no business running 3D games.
I can't say I disagree. Good 3D requires a hellva lot more than pushing a few polygons. At the very least, you'd need a bigger screen for a better FOV. And programming for a dinky 104MHz ARM? Reminds me of the days of RayCasters and home brew 3D engines. Ah, the memories.
Sadly, the best parts of the N-Gage were removed from the QD. I listen to the radio a lot on mine, and use it for a lot of MP3s and other media (especially since I can't sync my iPod what with the sbp2 layer being broken in Linux 2.6).
Do you really use it for Games that much, or do you like the N-Gage primarily for it's other features? If you just like an occasional Java game, then the Nokia 6800 series might be a better choice. Color screen, built-in radio, J2ME support, AND it flips open to reveal a full keyboard and joystick.
It gets worse: currently they're hardly addressing *the* most difficult concept for cheap reusable spacecraft: reentry. This single problem has contributed to the majority of the space shuttle's turnaround cost.
Arguably, the Space Shuttle's design is so poor because the Air Force wanted a relatively low altitude fly-by over Russian soil. Had the Space Shuttle been designed to Aero-brake much slower, it could have forgone the disposable heat shields. However, there is some question as to the difficulty in obtaining a proper flight envelope when entering the atmosphere at that shallow of an AOA.
Yes, but couldn't they just go higher and fall into orbit?
Attaining orbit is not a matter of height. It's a matter of going so fast that you continuously miss the Earth. The only reason why a space craft has to fly so high is that the thick atmosphere will slow it down.
There is also no 3D GPU -- it's all software rendering based around its main CPU, which is why it takes 144Mhz to do anything close to a PS1 level of graphics.
;-)
Yeah, I realized that after posting. It's a 104 MHz ARM processor that does both 2D and 3D. Granted, that's more power than my 486 had back when I was running Doom, MechWarrior, and Wing Commander 3, but it seems like it wouldn't quite be enough to port something like Red Faction. I'm guessing they take the old "cheat like hell" route.
but there is absolutely no IR support on the N-Gage
Oops, seems you're right. I misinterpreted a specs page as a "list of features" rather than a "checklist of features". IR had a red X next to it.
Linux was one hell of a lot piss poor than BSD at that point in time regardless of the couple of kilobytes that were removed from the BSD codebase. Before the 2.4.x kernels, only a GNU bigot would bother using Linux for anything.
Dude, you need to go MUCH farther back in time. When Linux came out, you needed a MINIMUM of a 286 AT machine to run BSD. Minix ran on an 8086. Linux attempted to copy the small footprint of Minix instead of the large footprint of BSD.
The reason for BSD's poor performance was that it was originally written for Mini-Computers (a serious step up from Micro-Computers) like VAXes and PDPs. PCs of the era lacked many of the computing features that made BSD and Unix possible. As a result, OSes had to simulate those features in software at a cost of CPU and memory.
Once PCs reached the stage of 386s, they were finally able to run Unixes without issue. Given BSD's 10+ years of development, it was obviously more advanced than Linux. It also helped that BSD was were all the "modern Unix technology" was developed. (e.g. TCP/IP, Fast File System, strong Multiuser support, etc.)
At the time Linux was being created, they had released an incomplete version of the system (Net Release 2) minus the AT&T source code that was still in the system.
You forget that Minix wasn't free either. BSD was an option, it was just a piss poor one.
They didn't design it like you suggested because you have more clue than Nokia
While that's an easy stance to take, I feel I should point out that the 6800 series of phones are also built by Nokia. Therefore someone in Nokia must have a clue, it just doesn't appear to be the ones who designed the N-Gage.
Perhaps the real problem with the N-GAGE form factor is that Nokia tried to pack too much stuff into it. The N-GAGE does games, Java, MP3s, Radio, Bluetooth, IR, and a bunch of other junk all while trying to be a phone. At the very least, the standard battery simply wouldn't be powerful enough for more than a half-hour of game time. A single game could result in serious draw by the following devices:
- Main CPU
- Bluetooth processor
- 3D GPU
- FM Digital Signal Processor
- LCD Color Display
- Standby GSM communications
Between all of those, I wouldn't be surprised if the power draw was somewhere around 3-10 Watts! ("Standby" power draw of a phone is usually less than a Watt.) You'd need a Laptop battery to power the thing for any appreciable amount of time. If Nokia had simply scaled back the device in a few areas, they might have had a good shot at a first gen device. Instead they overengineered it and guaranteed failure.
BTW, I think I know why you have to remove the battery to change the game. The Nokia engineers were probably stumped by the issue of making the user reboot the handheld before changing the cartrige. Game systems like the NES and Gameboy would actually lock the cartrige when they were turned on. Nokia's solution was to instead force people to remove the battery. This guarantees that the phone will be shut off when the cartriges are swapped and circumvents the requirement for a mechanical switch to lock the cartrige. It was still a dumb idea.
Err, the problem with Janeway wasn't that she was a non-jerkoff-material woman, but that her character was not convincing.
Indeed. If they'd made her more like Rachael Garret, THEN we'd have a captain to be proud of. Instead, we got Janeway who got all blurry-eyed at the slightest little thing Kes did. Oh, and her biggest moral dillema was whether or not to treat the Doctor like a Real Boy^H^H^H Person.
Inform me if I'm wrong, but didn't Linus make Linux because he didn't like Minix?
Not exactly. Minix was pretty much the only option other than BSD at the time, and BSD required some beefy hardware. The problem was that Tanenbaum didn't want to add the features necessary to make Minix a useful OS. He wanted it to be a teaching tool. The result was that Linus used Minix to bootstrap Linux development to fill the vacuum.
What I don't get is why Nokia didn't design it like the 6810. The 6810 even has a joystick! Just replace that keyboard with a DPad and buttons, and you'd be in business. Instead they thought that everyone would want to talk into something that looked like a reject from a Fischer Price factory. Go figure.
Except it's a lot easier to eat a few crackers than to undergo surgery to replace a battery.
You know, they used to use Plutonium to prevent this sort of problem. It was only after the whole Chernobyl scare that companies stopped producing pacemakers with long-life power sources. Sometimes I wonder how much of our technological "progression" is nothing more than an illusion.
Or maybe we just haven't learned yet to only use computers for the things they're good at and to drop the hype about them being good for everything in life.
I'm not sure I agree. It's hard to deny that computers *have* effected a change in business to the degree where the work of dozens of workers has been condensed into one person. Part of this can be attributed to programs like word processors and spreadsheets. Where a secretary and an accountant used to be a requirement for simple tasks, these tasks can now be accomplished without their assistance. Yet that doesn't explain web applications. How do web apps help? Do they even help at all?
The answer is truly a thing of beauty for businesses. Instead of paying a small army of typists and filers to keep the information organized, processed, and up to date, a web app allows a company to push the data entry to the customer. (Note that the customer feels this is a "feature".) And since the information is already is a computational device, it can be processed with little to no human interaction. So yes, computers are good at many things. The core of the problem is having someone who knows how to use them correctly.
PDA's are great, but a pencil and paper always beats every one of them for speed.
Depends on what you're doing. My wife is able to keep track of our checking account much more efficiently with her Palm Pilot. Ditto on her shopping list. It's also good for downloading and displaying recipes, and reading ebooks. It's NOT good at taking quick notes, or writing your next novel. And it definitely is not good at creating spreadsheets, surfing the web, listening to MP3s, or doing a zillion other things that people seem to think Palms should do.
Disks and filesystems are great, but an organized secretary with a well-laid-out file drawer will kick the PC's ass in knowledge about how all the information fits together, albeit she'll lose from a portability standpoint.
Agreed. But why can't she keep track of those same files in electronic form? That way she can make infinite copies at a whim, instantly transmit critical data anywhere in the world, and pull any file without leaving her desk. Project Managers and Business Analysts have long had to organize files for easy access. It's just that some are better than others. It might not be such a bad idea to make all filings run through a secretary rather than an open file server. Alternatively, the use of a meta-data file system can give many of the same advantages. If you tag each file with things like project, client, creator, etc., you'll develop many of the same indices that a filing secretary would.
And yet, what is the big money stuff in computers? Customer Relationship Management software.
Databases are generally A Good Thing(TM) as they allow for various computations to be done on that data. (Data Analysis is simply another form of computations.) Most CRM software sucks because it really ISN'T a database. It's really nothing more than a glorified (and confused) filing system. Put the data in a damn mainframe or SQL database and you'll find that you can generate much more useful reports.
We're another five to seven years from realizing that computers just simply don't do certain things well and they never will. It won't be an ephiphany or a sudden realiziation of these facts, people will just slowly migrate away from computers in areas they don't work well in, over time.
I don't think it's that easy. Generally, people want technology to move forward and are unwilling to back up and find a different path. What I do think is that the demand for software will decline, and users will come to the general realization that all they really need is some fairly basic boring application rather than the Gee-Whiz, Got-Pretty-Graphics-and-Features software of today. Software is simply too complex and is overdue for a simplification.
In many ways I feel
Star Trek Enterprise: "To boldly go and fuck up the entire timeline."
Haven't you been paying attention? According to Enterprise, history NEEDS a dumbass.
I don't have a problem with testing... because there's frankly no feasible substitute. An objective measure of knowledge has value if sufficiently rigorous. It definitely has value in medicine... but having never taken any sort of computer cert, I can't say whether that's the case for IT or not.
I think the problem in IT/IS/CompSci is that every developer has to be more like a Medical Researcher than a Doctor. In theory, a Doctor can do quite well with just "book-smarts" that tell him what to do in a given situation. And given how little is actually *well* understood about the human body, that's about all a Doctor can be expected to do. Obviously, a good Doctor will develop an intuition through experience, but most of what he does is still based on what the medical researchers tell him works.
In software development, we need less of "do this because it works" and more intuitive understanding of systems. To be really excellent you need to know both how the system works and what you don't know. You have to be willing to research the best way to get from point A to point B while juggling the various factors of cost, complexity, performance, and maintainability. No books or schoolwork can prepare you for this. It's simply something you can or can't do.
Unsurprisingly, a tremendous number of CompSci researchers and developers have spent decades trying to make this not the case. They've gone through 4th generation languages, GUI Builders, code generators, componentization, scripting, etc. all in hopes of finding a way to allow an average worker to produce excellent results. Sadly, every last attempt has failed. The problem appears to be that all of the "simplified" concepts are based on abstractions that simply aren't good enough. Once they hit the real world, project requirements cause the abstration to break down. This in turn requires that an experienced developer be able to understand what the system is doing from the bottom up. This then leads him back to the same issue of building the system to meet the needs of cost, complexity, performance, and maintanability.
Computer Scientists continue to hope for that "perfect abstraction", but it seems that it will never arrive. Perhaps the only leap forward will be when AI reaches a stage to where it can develop the work for you. But to reach that stage, we need orders of magnatude more computing power than we have today. Not to mention that our mathematical models for solving problems will have to get that much better, and that much more complex.
Maybe, just maybe, the computer as we know it today is an inherently flawed concept? At its core, it really is nothing more than a computational device. i.e. It does math very well. But what we ask it to do today has almost nothing to do with math. We simply push around data to achieve results that appear to be digital representations of physical things. Yet the real world is analog. Do we need an analog "brain" rather than a digital computer?
I personally think that more employers should give a short test as part of the interview, this way they can be fairly confident that the person they are hiring actually knows how to do the job.
:-( It's especially amusing when one considers that I converse with these people online quite often, but never meet one in real life. (The ones I know online are never where I am at the moment.) We must be extremely rare.
I actually did something similar when I was recently interviewing junior programmer candidates. When I noticed that they had "Masters Degree" written all over their resume, I decided to put them through the wringer and ask about various data structures and search algorithms. (Note: I never got a degree myself. Too busy actually performing the job.) I usually started with something complex like Hashtables, then went progressively simpler to Binary Searches, B-Trees, and Linked Lists. Oddly enough, no one knew how hashtables worked. One guy stuttered through so badly that he barely even managed to explain linked lists (and I wasn't tremendously happy with his explanation). The guy I ended up recommending was the one who simply said "I don't know" to the ones he didn't know, and gave detailed explanations of the ones he did know.
Of course, none of this would tell me if the guy could write *good* software. But at least I'd know that he had the basics and could be taught. If it had been a more senior position, I would have taken great care in attempting to find public examples of their work, and spend time chatting to ascertain how passionate they actually are about technology. Sadly, I can't say that I've interviewed a single person who has actually wowed me.
BTW, if you're looking for the type of API I'd demonstrate to a tech interviewer, look no farther than my GAGE gaming APIs. The API is clean, the code is simple, and the algorithms are original and unmatched. If I saw something similar out of a candidate, I would go throttle my manager until he was hired. Too bad that pretty much all senior candidates I've dealt with don't even have code to show.
After reading this, I just had a horrible vision of ASCII Clippy integrated into vi.
Ask, and ye shall receive.
Mwhahahahaha, mwhahahah, HAHAHAHAHAHAAAA!!!
(Okay, so he isn't ASCII. Deal with it.)
The programmer and time are not fungible. We cannot simple expect to complete a project that takes 1 man 18 months with 18 men in 1 month. As you add more men the time improvements become less and less.
;-)
In other words, programmers tend to run afoul of Amdahl's Law.
Actually, Amdahl's Law would probably be a good way of calculating the maximum effective team size. Unfortunately, it can be very difficult to ascertain a value for the "work" needed on a project. Not to mention the "human factor" of programmers who are faster, less experienced programmers, and "cowboy coders" who refuse to check any of their work into version control.