I've had an N-Gage QD for a bit over a year (got it on clearance).
Likes:
* Bluetooth very open (you can up/download a lot more than on most phones).
* J2ME implementation reasonably useful (I've popped a couple of my J2ME apps on there and they run well).
* MMC expandability (nice with the ogg player you can get for it).
* Works really well as a phone (better than my wife's Sidekick II and our roommate's cheapo Moto).
Dislikes:
* Control on games is so-so (right thumb gets tired after a while on, say, Rayman).
* Games themselves are rehashes mostly, were expensive when new.
I really like the idea of a phone with casual games (waste time when, say, waiting in line or similar). I really hate the idea of a phone with "serious" games. I don't have time for serious gaming on the go (indeed, I have a PSP, but don't carry it everywhere I go as I do my N-Gage). Short version for phone gaming:
* Popcap-ish games: good idea
* Mega-huge FPS or RPG: bad idea
If N-Gage II (or whatever they'll call it) is as open as this generation, and especially if they make it easier to write games for it, I'll probably buy one. Doubly so if it's easy to get small developers onboard. If not, I'll get something else as my next phone.
The older, the better, but I'd think that finding an SE shouldn't be too hard. Even better if you can find a foreign System stack (the experience I had in high school playing with a Japanese machine was interesting for both it's GUIness and its ease-of-transition to another language).
I've been a professional Windows SA and a professional Linux SA in various parts of my career. Relevant observations follow.
Installation:
Windows - Nearly trivial if all you care about is MS tech and don't need a database. Somewhat less so if you need, say, php and a database. Integration can be mitigated across several systems via Ghosting. Er, not really server-side. Ghosting IIRC is rather verboten in Microsoft's mind.
Linux - Trivial if you use the distro's packages. Significantly less so if you need to integrate, say, Tomcat with Sun JVM or Oracle. Integration and configuration can me mitigated across several systems via configuration management (cvs, svn) or via scripting or via just copying working configuration files to server #n+1.
Configuration:
Windows - Simple if you're not doing anything terribly interesting (and most people don't). Configuration replication is significantly more difficult. Incremental configuration changes (e.g. adding another site) can be scripted if you REALLY know what you're doing or are using third-party tools like Plesk.
Linux - Somewhat complicated if starting from scratch, especially with Apache 1.3 and single config files. Easier if starting with Apache2 and separate config files. Integration of third-party things can be somewhat difficult. Easy to "roll back" changes using a configuration management system, and relatively easy to script incremental configuration changes.
Updates:
Windows - Easy for base system via Windows Update. Somewhat more work for third-party components.
Linux - Easy for base system and perhaps all components that would be considered third-party above. Somewhat more work for third-party components (but the list of "third party components" is smaller than that for Windows, as PHP/MySQL/Postgres/Whatever are part of the distro).
Performance:
I think the endless performance arguments are counterproductive. Linux "feels" faster, but that's not quantifiable, and there are countless ways that tests can be structured to optimize for one architecture or another, especially once you toss application layers (xxMP, Tomcat, CF, etc etc) in there. If performance really matters that much, an organization probably has enough resources that they can make a better evaluation for their payloads than politically-motivated third parties anyway.
Conclusion:
I'm not really going to say anything that others haven't said better elsewhere. If you're looking at one departmental or small business web server, Windows is probably easier to start out with, especially if you don't have the talent to grok Linux right off the bat (that gap is shrinking year-over-year, but it's still there). Once you're looking at any real scale (and want to do things like actually replicate configurations and the like), Linux is far more useful and probably cheaper in scale.
That said, Hostbasket itself charges less for its Linux offering than it's Windows one, and (at the most conservative), Windows is more expensive in every area except labor and (bizarrely) bandwidth if you multiply out the percentages with the calculated TCO number. They're showing Linux as 3.5x more expensive in labor than.NET 2.0, which is dubious in my mind. There's a story here that's not being told--3.5x is a huge jump and there's got to be either a juicy story here that looks bad for Linux (unlikely, or it would've been publicized) or something structural that may invalidate the whole study (more likely, by elimination).
This is a good idea, believe it or not. Many years ago, I had a case of hubris where I thought I could write an OS in pure assembly. I took a week off of work to give a go at jumpstarting the process. The OS I produced: Er, none. What I learned?
How DLLs, particularly linking/loading at compile- and run-time, work at a low level.
The innards of three filesystems.
Solutions to various bit manipulation problems in assembly.
General implementation of hardware-assisted task switching (i.e. saving/restoring registers, etc.)
...and dozens of other esoteric (but later quite useful) topics I can't remember off the top of my head...
Being a good programmer means challenging yourself--via coding competition (TopCoder, e.g.), weird language acquisition (Haskell seems to be a favorite nowadays), or outrageous tasks (as I did above).
Picking a favorite OSS program and putting in extra bits is a good thing, too. I did that (though wasn't able to contribute back due to bureaucratic nonsense at my company) with PXELinux and the Linux loop.c driver, for example. Bummer that I could never release the changes, but at least I refreshed my x86 assembly (PXELinux) and learned some kernel driver basics (loop.c).
Just make sure your company doesn't own your work produced on both on- and off-company time. Ugh.
I'm a 31-year-old student and finishing up in 12-18 months at the rate I'm going.
I'll mirror what most other folks here have said, namely that you're not too old for college or to enter one of many CS-type careers and that you should go for it. I will make one small detour from the norm, however, and suggest you might want to make a small adjustment to your major--and not for the reasons you may suspect.
The only CSUs that appear to have actual SoftE programs are San Jose State and CSU Fullerton. Since the Fullerton program is a Master's-only program, I'll assume that you're probably looking at SJSU.
And I just happen to be an SJSU student.
While the SJSU SoftE program is terrific, there are a LOT of very specific courses in the program. It is simply not well laid-out for folks looking to transfer in from other schools (or for those looking for a second bachelor's) IMHO. When I transferred over, I initially applied for SoftE, but changed my mind once I worked it out on a spreadsheet. It turned out that, even though I had previously earned an Associate's in Engineering (and therefore had taken a bunch of engineering classes), SoftE was 9 credit hours (or about 1.5 part-time semesters) more than plain old CS. The problem is that SoftE in particular is a fairly inflexible program with a lot of boxes to check off.
Then again, SJSU has one of the best CompE programs anywhere, and many of the SoftE classes correspond directly with CS classes, especially at the start (so you can change your mind later if you want).
The moral of the story (regardless of where you go) is that you should scour your requirements and see what will suit you best. For someone who's coming in as a freshman, it probably doesn't matter too much, but it's huge for a returning/transferring/second bachelor's student.
Just to allay confusion, the Avocent AutoView 2000 noted in parent is KVM-over-Cat5, NOT KVM-over-IP. Big difference, since IP is routable across the WAN and whatever (presumably analog) signal on Cat5 is not.
That said, KVM-over-Cat5 isn't a bad way to make a room accessable from outside...
I currently work for Sun's Network Systems Group (x64 servers). I use a SunRay to do the vast bulk of my work every day. I have run my own SunRay servers (running Linux) for over two years.
I used to work for a company called Taos, whose user infrastructure was entirely Windows Terminal Services + Citrix Metaframe. Another SA and I ran their terminal servers for my entire tenure there (about 2.5 years, plus I was doing application development at the same time).
The Response:
Those who hate thin clients (TCs for short) tend to do so for the following reasons:
1. Initial procurement cost and software licensure is no cheaper than desktops. For some software (the Citrix bits in particular), it's significantly more expensive. 2. Users can't (or damn well shouldn't be able to) run arbitrary software--the joke "screensaver" that their friend sent them, for example ("screensavers" are just eye candy anyway--who cares about saving a CRT anymore?). 3. Performance with certain apps (video in particular) is highly network-bound and potentially crappy. 4. Limited number of points of failure, so a dead server can affect many people. 5. "What do you mean I can't plug my webcam/phone/food processor in there?"
Most of these arguments are lame, because:
1. Thin client hardware has MUCH better longevity than its desktop bretheren--five or more years out of TC hardware is the rule, not the exception. 2. Users shouldn't be running arbitrary software anyway in most business settings. 3. Performance with most other apps is stellar, as the first user to load an app "greases the skids," putting most of the app in cache for everyone else. 4. If you do it right, you have configured your server to be relatively bulletproof, and have one or more backups (typically folks don't have backup desktop machines:-/ ). Plus, many people's work is network bound--a dead conventional server means people can't save stuff or can't update the company database (or whatever they're doing) anyway, making the desktop of little real use when their related servers (or the network generally) go down. 5. Is more-or-less valid. There are some devices that simply will not work when attached to TC hardware (though a surprisingly large number of things will). Whether that's really a problem or not is in the eyes of the beholder.
You also get the following benefits out of TCs:
1. No crawling under a desk and facing the Dust Bunny Army (tm) to replace a dead drive, or removing 20 lbs of personal effects to upgrade someone's RAM. 2. True centralized deployment of software--no guessing if an app got installed or WTF is actually on someone's hard drive (deployment solutions for PCs other than ghosting the whole drive have this nasty habit of being fidgety). 3. With some solutions (Citrix in particular), you can "publish" an application, making just one app available to those who MUST use a PC, so you can mix-and-match your clients if needbe. 4. Usability over slower WAN links is usually pretty good (especially with Citrix). 5. Some solutions (particularly SunRay on Linux or Solaris) allow session "portability," which means that you can start typing a sentence, pull out your card, walk down the hallway (to, say, a meeting room), plop in your card and finish your sentence. To those that have never tried it, this seems silly. To those who use it daily, it's a Godsend (like those who are addicted to TiVo, SunRay session portability is something you just have to "get"). 6. TC hardware is generally SILENT and consumes very little electricity.
SAs, like any users, hate TCs because they're "limited" in what they can do. The smart ones end up loving TCs precisely because users are limited in what they can do. That said, you also have to deal with the real TC problems:
1. Some apps just won't behave, or they require a ton of work to behave. This problem has gotten better with time, but stories abound of ba
SPARC and PowerPC are pretty clearly niche and/or legacy architectures now. IBM has ceded the mainstream desktop to x86, and SPARC lost that battle a long time ago. The only question most people care about now is whether their x86 system is 32 or 64 bit, Intel or VIA or AMD.
Unless we're talking about the 100x or so more machines in the embedded space. Just because the chip isn't in a PeeCee doesn't mean it's not a computer. And embedded designers DO care about this stuff.
Everyone has to deal with this at some point, and everyone's going to have a different opinion about it.
When you're talking to superiors, use whatever language they want, standing your ground only when someting REALLY bugs you (like I do when folks ask if I "have enough bandwidth" to do something unrelated to data transmission). When talking to folks not your superior, use whatever language you want that is clear and effective. This way, you get the best of both worlds for (IMHO) marginal effort.
When you do pick a battle, in general you want to make sure it's private and the evidence is overwhelming (nobody likes being corrected by an underling in front of their peers).
Now if only we could get folks to stop mis-using "tragic." Consequences can only be tragic in the traditional definition if preceeded by an act of hubris (look it up). It's gotten bad enough, however, that dictionaries are generalizing the definition to match the evening news, so the battle may already be lost:-(.
I'd do that, but I'm a hybrid java developer/IT d00d. Most IT folk I know wouldn't touch a profiler with a 10-foot pole, much less write one and semi-build it into an app. This is a programming topic, not an IT one.
I'm a sysadmin for several dozen engineers, and the approach I've taken is to writing the tools they need to do their jobs, toss the tools at them, and let them do their thing.
If you're controlling resources, they should be able to allocate that stuff themselves and you should do just that--stay out of the way.
If you're a service provider (doing the stuff they don't want to do), you don't need to ask/. what you're in for--they'll tell you explicitly and soon.
If you're in the position of defusing a contentious situation (like person A wants resource X, but so does person B and management can't make up their minds)... Er... Well... Good friggin' luck then.
As many have reiterated here. The biggest thing you can do to alienate an applicant is to not respond. Always respond. Period. You might not want to say "sorry, Charlie," but you must. Don't chicken out.
Second, when someone goes to the trouble of making your life easier (say, by writing a resume weblication that spits out a resume in any form you want), take the time to use it. I can't believe that a "Click here to download as a.DOC" link is inferior to an email attachment. Ugh.
Our fear is that a label may become unreadable due to heat exposure sometime during mailing. Even if label damage due to heat is rare, we cannot afford to take a chance since many of the documents we mail are time-sensitive.
The odds of thermal labels not surviving transit due to their composition isn't "rare." It's much closer to "zero." I used to work for UPS tech support and have seen all kinds of labelling problems but never have I seen one illegible due to yellowing or thermal damage. Never. One day, I even stuck a thermal label to a black lamppost in Phoenix in summer--it was a year before it yellowed at all.
Don't worry about thermal tech. Seriously. Worst case, slap some packing tape on top if you're worried about grease/oil/etc.
I just started my upper-division work at a uni similiar to Smartypants U. My earlier experiences, however, include:
1. Top AP scores (5) on Calculus AB and Physics, and a really good (4) score on English Lit/Comp. 2. Four semesters of partial failure at my first Smartypants U, much of which didn't transfer. 3. Computer-type vocational training at a Community College (that didn't transfer at all), and finally: 4. 30 or so hours at another CC to finish up an Engineering Associate's and make damn sure my time at the uni was minimized (i.e. no GE, nothing at the uni that I could take at the CC).
What I've learned from all this is that the CC is the best value for the time and the money from both a hours-treadmill perspective and from a "what you actually learn" perspective. Period. Too many full-on universities (or at least uni profs) ignore the educational needs of their students, and Engineering, CS and other Math and Science-related degrees are too damned hard to entrust smart students to people who don't care.
Community college instructors, on the other hand, generally have no writing/research requirement, and often have interesting day jobs that directly relate to their material. They are generally better at teaching (as opposed to researching), and there are never any TAs that the class is pawned off onto. Lecture-hall classes of hundreds of students are unheard of (common in lower-division at big unis), and class sizes are generally smaller overall. At best, CC instructors match up nicely with the better uni profs, and at worst, they're at least waaaay less expensive and distracted.
Furthermore, if you live in a state where the CC and uni systems are tight (like in California), there are things like direct course articulation (e.g. http://artic.sjsu.edu/ and general ed certification, so you can plan for and avoid transfer pitfalls. And CCs are at least an order of magnitude cheaper. As long as you stick to stuff that will transfer, you (and whoever's financing you) WILL be happier at a CC than slogging your way through lower-division at a big uni.
I enthusiastically recommend CCs to all incoming freshmen and to anyone returning to school with lower-division left to complete, doubly so if their planned major is tough. CCs might not get much respect in the academic world, but they are far and away the best bridge from the generally conscientious (and professional) educators in high school to the part-time, often lackluster educators in big unis. While not necessarily all CC instructors are top-drawer, they're far better as a class than those at Smartypants U, and far cheaper.
Did You Design Crack Cocaine, Too?
on
Ask Sid Meier
·
· Score: 1
I swear, Civ, Colonization, and Pirates are just as addictive...
I've done sites in PHP (Makeuptracker), Java Servlets + JSP (Prayer Supply), and other technologies, and based on what you've said so far, there's no compelling reason to not use PHP if that's what you want.
On the other hand, there's no real reason to not use JSP, servlets, or any of a half-dozen other environments, either. The reality is that your site is unlikely to be overly sensitive to environment and that any half-decently-coded implementation in any tech is likely to work at least acceptably.
Thus you have a problem where the solutions aren't really distinguishing themselves a great deal. So come up with some more metrics--is technology X something you really want to learn? Do you want to be able to use a cheaper hosting service (PHP is common on cheap hosts, app servers not so much)? These sorts of questions are the ones you should probably be asking...
There seem to be two general sorts of responses here:
1. Evolution IS just a theory, so what's the problem? 2. Evolution has been observed, so it IS fact, and the sticker is wrong.
The fact vs theory debate has been beaten to death by other posters, but questioning the statement by itself is insufficient. The question must be taken in context of the content of the book. If the book is truly written in a "this is all fact" manner, then the sticker is correct (or at least plausable)--even the most pro-evolution scientist will readily admit that not everything evolution-related is fact (though it's damn well-supported theory).
That the same can be said for any physical science is irrelevant, and that the motivations of the sticker proponents are dubious is also irrelevant. There's a wide gap between "take this evolution thing with a grain of salt" and "this is a load of crap but we're forced to teach it to you. Praise Jesus!"
The whole sticker thing may be a supremely dumb waste of time and resources, but unconstitutional? If a case could be reasonably made that the book's wording miscategorizes evolution fact (observed speciation, etc.) with evolution theory, then there is no constitutional question here.
1. Leaders who are actually somewhat accountable to YOU, 2. Leaders who actually represent YOU, and 3. To not be so horribly frustrated with democracy, then...
Do your RESEARCH and vote for your local officials in an informed manner. Many people are disenfranchised by the democratic process precisely because they only watch the news (which is only interested in big elections). The fact is that only your LOCAL leaders will, as a general rule, affect you personally. The likelihood that Bush or Kerry will impact you personally is basically zero. The likelihood that your Mayor, State Representatives, or local districtpeople will have a direct impact on you, your children, your neighbors, etc.
If you don't check a box for president, big deal. If you pick your local folks at random, on party lines, or because you like the sound of their name, you deserve what you get.
Start your research with whatever your Secretary of State sent you, or go online to e.g. http://www.smartvoter.org/ (CA and OH, mostly, others linked).
Seriously. Why not have something like this? For simple OS+apps, 10GB is still overkill (my main PC at home has only ~4GB used, and it'd be even less compressed). I don't even think SCSI is necessary--just put it on a PCI card and emulate an IDE bridge (fast) or use e.g. Serial ATA as an interface (slower, but more compatible).
For video and whatnot, sure. Use a conventional HD. But for OS and apps to be smokin' fast, battery-backed RAM is the way to go.
Slashdot Mirror
I've had an N-Gage QD for a bit over a year (got it on clearance).
Likes:
* Bluetooth very open (you can up/download a lot more than on most phones).
* J2ME implementation reasonably useful (I've popped a couple of my J2ME apps on there and they run well).
* MMC expandability (nice with the ogg player you can get for it).
* Works really well as a phone (better than my wife's Sidekick II and our roommate's cheapo Moto).
Dislikes:
* Control on games is so-so (right thumb gets tired after a while on, say, Rayman).
* Games themselves are rehashes mostly, were expensive when new.
I really like the idea of a phone with casual games (waste time when, say, waiting in line or similar). I really hate the idea of a phone with "serious" games. I don't have time for serious gaming on the go (indeed, I have a PSP, but don't carry it everywhere I go as I do my N-Gage). Short version for phone gaming:
* Popcap-ish games: good idea
* Mega-huge FPS or RPG: bad idea
If N-Gage II (or whatever they'll call it) is as open as this generation, and especially if they make it easier to write games for it, I'll probably buy one. Doubly so if it's easy to get small developers onboard. If not, I'll get something else as my next phone.
The older, the better, but I'd think that finding an SE shouldn't be too hard. Even better if you can find a foreign System stack (the experience I had in high school playing with a Japanese machine was interesting for both it's GUIness and its ease-of-transition to another language).
I've been a professional Windows SA and a professional Linux SA in various parts of my career. Relevant observations follow.
.NET 2.0, which is dubious in my mind. There's a story here that's not being told--3.5x is a huge jump and there's got to be either a juicy story here that looks bad for Linux (unlikely, or it would've been publicized) or something structural that may invalidate the whole study (more likely, by elimination).
Installation:
Windows - Nearly trivial if all you care about is MS tech and don't need a database. Somewhat less so if you need, say, php and a database. Integration can be mitigated across several systems via Ghosting. Er, not really server-side. Ghosting IIRC is rather verboten in Microsoft's mind.
Linux - Trivial if you use the distro's packages. Significantly less so if you need to integrate, say, Tomcat with Sun JVM or Oracle. Integration and configuration can me mitigated across several systems via configuration management (cvs, svn) or via scripting or via just copying working configuration files to server #n+1.
Configuration:
Windows - Simple if you're not doing anything terribly interesting (and most people don't). Configuration replication is significantly more difficult. Incremental configuration changes (e.g. adding another site) can be scripted if you REALLY know what you're doing or are using third-party tools like Plesk.
Linux - Somewhat complicated if starting from scratch, especially with Apache 1.3 and single config files. Easier if starting with Apache2 and separate config files. Integration of third-party things can be somewhat difficult. Easy to "roll back" changes using a configuration management system, and relatively easy to script incremental configuration changes.
Updates:
Windows - Easy for base system via Windows Update. Somewhat more work for third-party components.
Linux - Easy for base system and perhaps all components that would be considered third-party above. Somewhat more work for third-party components (but the list of "third party components" is smaller than that for Windows, as PHP/MySQL/Postgres/Whatever are part of the distro).
Performance:
I think the endless performance arguments are counterproductive. Linux "feels" faster, but that's not quantifiable, and there are countless ways that tests can be structured to optimize for one architecture or another, especially once you toss application layers (xxMP, Tomcat, CF, etc etc) in there. If performance really matters that much, an organization probably has enough resources that they can make a better evaluation for their payloads than politically-motivated third parties anyway.
Conclusion:
I'm not really going to say anything that others haven't said better elsewhere. If you're looking at one departmental or small business web server, Windows is probably easier to start out with, especially if you don't have the talent to grok Linux right off the bat (that gap is shrinking year-over-year, but it's still there). Once you're looking at any real scale (and want to do things like actually replicate configurations and the like), Linux is far more useful and probably cheaper in scale.
That said, Hostbasket itself charges less for its Linux offering than it's Windows one, and (at the most conservative), Windows is more expensive in every area except labor and (bizarrely) bandwidth if you multiply out the percentages with the calculated TCO number. They're showing Linux as 3.5x more expensive in labor than
Re: Insane Programming Task
This is a good idea, believe it or not. Many years ago, I had a case of hubris where I thought I could write an OS in pure assembly. I took a week off of work to give a go at jumpstarting the process. The OS I produced: Er, none. What I learned?
Being a good programmer means challenging yourself--via coding competition (TopCoder, e.g.), weird language acquisition (Haskell seems to be a favorite nowadays), or outrageous tasks (as I did above).
Picking a favorite OSS program and putting in extra bits is a good thing, too. I did that (though wasn't able to contribute back due to bureaucratic nonsense at my company) with PXELinux and the Linux loop.c driver, for example. Bummer that I could never release the changes, but at least I refreshed my x86 assembly (PXELinux) and learned some kernel driver basics (loop.c).
Just make sure your company doesn't own your work produced on both on- and off-company time. Ugh.
...if you really want to hate, how 'bout brainf*ck?
They have goals, so do you. Evaluate accordingly.
Gotta second this one. Black scientist in the deep South trying to convince farmers to grow peanuts and sweet potatoes to renew the soil...
r ver
http://www.answers.com/topic/george-washington-ca
I'm a 31-year-old student and finishing up in 12-18 months at the rate I'm going.
I'll mirror what most other folks here have said, namely that you're not too old for college or to enter one of many CS-type careers and that you should go for it. I will make one small detour from the norm, however, and suggest you might want to make a small adjustment to your major--and not for the reasons you may suspect.
The only CSUs that appear to have actual SoftE programs are San Jose State and CSU Fullerton. Since the Fullerton program is a Master's-only program, I'll assume that you're probably looking at SJSU.
And I just happen to be an SJSU student.
While the SJSU SoftE program is terrific, there are a LOT of very specific courses in the program. It is simply not well laid-out for folks looking to transfer in from other schools (or for those looking for a second bachelor's) IMHO. When I transferred over, I initially applied for SoftE, but changed my mind once I worked it out on a spreadsheet. It turned out that, even though I had previously earned an Associate's in Engineering (and therefore had taken a bunch of engineering classes), SoftE was 9 credit hours (or about 1.5 part-time semesters) more than plain old CS. The problem is that SoftE in particular is a fairly inflexible program with a lot of boxes to check off.
Then again, SJSU has one of the best CompE programs anywhere, and many of the SoftE classes correspond directly with CS classes, especially at the start (so you can change your mind later if you want).
The moral of the story (regardless of where you go) is that you should scour your requirements and see what will suit you best. For someone who's coming in as a freshman, it probably doesn't matter too much, but it's huge for a returning/transferring/second bachelor's student.
Just to allay confusion, the Avocent AutoView 2000 noted in parent is KVM-over-Cat5, NOT KVM-over-IP. Big difference, since IP is routable across the WAN and whatever (presumably analog) signal on Cat5 is not.
That said, KVM-over-Cat5 isn't a bad way to make a room accessable from outside...
Heh. First +5 I've had in quite some time (maybe ever). Go fig.
Obligatory Background:
:-/ ). Plus, many people's work is network bound--a dead conventional server means people can't save stuff or can't update the company database (or whatever they're doing) anyway, making the desktop of little real use when their related servers (or the network generally) go down.
I currently work for Sun's Network Systems Group (x64 servers). I use a SunRay to do the vast bulk of my work every day. I have run my own SunRay servers (running Linux) for over two years.
I used to work for a company called Taos, whose user infrastructure was entirely Windows Terminal Services + Citrix Metaframe. Another SA and I ran their terminal servers for my entire tenure there (about 2.5 years, plus I was doing application development at the same time).
The Response:
Those who hate thin clients (TCs for short) tend to do so for the following reasons:
1. Initial procurement cost and software licensure is no cheaper than desktops. For some software (the Citrix bits in particular), it's significantly more expensive.
2. Users can't (or damn well shouldn't be able to) run arbitrary software--the joke "screensaver" that their friend sent them, for example ("screensavers" are just eye candy anyway--who cares about saving a CRT anymore?).
3. Performance with certain apps (video in particular) is highly network-bound and potentially crappy.
4. Limited number of points of failure, so a dead server can affect many people.
5. "What do you mean I can't plug my webcam/phone/food processor in there?"
Most of these arguments are lame, because:
1. Thin client hardware has MUCH better longevity than its desktop bretheren--five or more years out of TC hardware is the rule, not the exception.
2. Users shouldn't be running arbitrary software anyway in most business settings.
3. Performance with most other apps is stellar, as the first user to load an app "greases the skids," putting most of the app in cache for everyone else.
4. If you do it right, you have configured your server to be relatively bulletproof, and have one or more backups (typically folks don't have backup desktop machines
5. Is more-or-less valid. There are some devices that simply will not work when attached to TC hardware (though a surprisingly large number of things will). Whether that's really a problem or not is in the eyes of the beholder.
You also get the following benefits out of TCs:
1. No crawling under a desk and facing the Dust Bunny Army (tm) to replace a dead drive, or removing 20 lbs of personal effects to upgrade someone's RAM.
2. True centralized deployment of software--no guessing if an app got installed or WTF is actually on someone's hard drive (deployment solutions for PCs other than ghosting the whole drive have this nasty habit of being fidgety).
3. With some solutions (Citrix in particular), you can "publish" an application, making just one app available to those who MUST use a PC, so you can mix-and-match your clients if needbe.
4. Usability over slower WAN links is usually pretty good (especially with Citrix).
5. Some solutions (particularly SunRay on Linux or Solaris) allow session "portability," which means that you can start typing a sentence, pull out your card, walk down the hallway (to, say, a meeting room), plop in your card and finish your sentence. To those that have never tried it, this seems silly. To those who use it daily, it's a Godsend (like those who are addicted to TiVo, SunRay session portability is something you just have to "get").
6. TC hardware is generally SILENT and consumes very little electricity.
SAs, like any users, hate TCs because they're "limited" in what they can do. The smart ones end up loving TCs precisely because users are limited in what they can do. That said, you also have to deal with the real TC problems:
1. Some apps just won't behave, or they require a ton of work to behave. This problem has gotten better with time, but stories abound of ba
It doesn't quite work this way for PPPoE (which is why he singled out DSL). PPPoE is more like really-high-speed dialup.
I'm not sure about TFA's logic overall, but he had a point when it comes to most contemporary DSL.
SPARC and PowerPC are pretty clearly niche and/or legacy architectures now. IBM has ceded the mainstream desktop to x86, and SPARC lost that battle a long time ago. The only question most people care about now is whether their x86 system is 32 or 64 bit, Intel or VIA or AMD.
Unless we're talking about the 100x or so more machines in the embedded space. Just because the chip isn't in a PeeCee doesn't mean it's not a computer. And embedded designers DO care about this stuff.
Everyone has to deal with this at some point, and everyone's going to have a different opinion about it.
:-(.
When you're talking to superiors, use whatever language they want, standing your ground only when someting REALLY bugs you (like I do when folks ask if I "have enough bandwidth" to do something unrelated to data transmission). When talking to folks not your superior, use whatever language you want that is clear and effective. This way, you get the best of both worlds for (IMHO) marginal effort.
When you do pick a battle, in general you want to make sure it's private and the evidence is overwhelming (nobody likes being corrected by an underling in front of their peers).
Now if only we could get folks to stop mis-using "tragic." Consequences can only be tragic in the traditional definition if preceeded by an act of hubris (look it up). It's gotten bad enough, however, that dictionaries are generalizing the definition to match the evening news, so the battle may already be lost
...or a legal OS, if we're talking about a MS drone...
(or at least part of a legal OS. How much is the MS tax nowadays?)
Seriously. Modifying a program to profile it?
I'd do that, but I'm a hybrid java developer/IT d00d. Most IT folk I know wouldn't touch a profiler with a 10-foot pole, much less write one and semi-build it into an app. This is a programming topic, not an IT one.
...or...
/. what you're in for--they'll tell you explicitly and soon.
Automate it, then get outta the way.
I'm a sysadmin for several dozen engineers, and the approach I've taken is to writing the tools they need to do their jobs, toss the tools at them, and let them do their thing.
If you're controlling resources, they should be able to allocate that stuff themselves and you should do just that--stay out of the way.
If you're a service provider (doing the stuff they don't want to do), you don't need to ask
If you're in the position of defusing a contentious situation (like person A wants resource X, but so does person B and management can't make up their minds)... Er... Well... Good friggin' luck then.
As many have reiterated here. The biggest thing you can do to alienate an applicant is to not respond. Always respond. Period. You might not want to say "sorry, Charlie," but you must. Don't chicken out.
.DOC" link is inferior to an email attachment. Ugh.
Second, when someone goes to the trouble of making your life easier (say, by writing a resume weblication that spits out a resume in any form you want), take the time to use it. I can't believe that a "Click here to download as a
Our fear is that a label may become unreadable due to heat exposure sometime during mailing. Even if label damage due to heat is rare, we cannot afford to take a chance since many of the documents we mail are time-sensitive.
The odds of thermal labels not surviving transit due to their composition isn't "rare." It's much closer to "zero." I used to work for UPS tech support and have seen all kinds of labelling problems but never have I seen one illegible due to yellowing or thermal damage. Never. One day, I even stuck a thermal label to a black lamppost in Phoenix in summer--it was a year before it yellowed at all.
Don't worry about thermal tech. Seriously. Worst case, slap some packing tape on top if you're worried about grease/oil/etc.
I just started my upper-division work at a uni similiar to Smartypants U. My earlier experiences, however, include:
1. Top AP scores (5) on Calculus AB and Physics, and a really good (4) score on English Lit/Comp.
2. Four semesters of partial failure at my first Smartypants U, much of which didn't transfer.
3. Computer-type vocational training at a Community College (that didn't transfer at all), and finally:
4. 30 or so hours at another CC to finish up an Engineering Associate's and make damn sure my time at the uni was minimized (i.e. no GE, nothing at the uni that I could take at the CC).
What I've learned from all this is that the CC is the best value for the time and the money from both a hours-treadmill perspective and from a "what you actually learn" perspective. Period. Too many full-on universities (or at least uni profs) ignore the educational needs of their students, and Engineering, CS and other Math and Science-related degrees are too damned hard to entrust smart students to people who don't care.
Community college instructors, on the other hand, generally have no writing/research requirement, and often have interesting day jobs that directly relate to their material. They are generally better at teaching (as opposed to researching), and there are never any TAs that the class is pawned off onto. Lecture-hall classes of hundreds of students are unheard of (common in lower-division at big unis), and class sizes are generally smaller overall. At best, CC instructors match up nicely with the better uni profs, and at worst, they're at least waaaay less expensive and distracted.
Furthermore, if you live in a state where the CC and uni systems are tight (like in California), there are things like direct course articulation (e.g. http://artic.sjsu.edu/ and general ed certification, so you can plan for and avoid transfer pitfalls. And CCs are at least an order of magnitude cheaper. As long as you stick to stuff that will transfer, you (and whoever's financing you) WILL be happier at a CC than slogging your way through lower-division at a big uni.
I enthusiastically recommend CCs to all incoming freshmen and to anyone returning to school with lower-division left to complete, doubly so if their planned major is tough. CCs might not get much respect in the academic world, but they are far and away the best bridge from the generally conscientious (and professional) educators in high school to the part-time, often lackluster educators in big unis. While not necessarily all CC instructors are top-drawer, they're far better as a class than those at Smartypants U, and far cheaper.
I swear, Civ, Colonization, and Pirates are just as addictive...
Use the best tool for the job.
</obCopout>
OK, now that's out of the way, I'll say this:
I've done sites in PHP (Makeuptracker), Java Servlets + JSP (Prayer Supply), and other technologies, and based on what you've said so far, there's no compelling reason to not use PHP if that's what you want.
On the other hand, there's no real reason to not use JSP, servlets, or any of a half-dozen other environments, either. The reality is that your site is unlikely to be overly sensitive to environment and that any half-decently-coded implementation in any tech is likely to work at least acceptably.
Thus you have a problem where the solutions aren't really distinguishing themselves a great deal. So come up with some more metrics--is technology X something you really want to learn? Do you want to be able to use a cheaper hosting service (PHP is common on cheap hosts, app servers not so much)? These sorts of questions are the ones you should probably be asking...
There seem to be two general sorts of responses here:
1. Evolution IS just a theory, so what's the problem?
2. Evolution has been observed, so it IS fact, and the sticker is wrong.
The fact vs theory debate has been beaten to death by other posters, but questioning the statement by itself is insufficient. The question must be taken in context of the content of the book. If the book is truly written in a "this is all fact" manner, then the sticker is correct (or at least plausable)--even the most pro-evolution scientist will readily admit that not everything evolution-related is fact (though it's damn well-supported theory).
That the same can be said for any physical science is irrelevant, and that the motivations of the sticker proponents are dubious is also irrelevant. There's a wide gap between "take this evolution thing with a grain of salt" and "this is a load of crap but we're forced to teach it to you. Praise Jesus!"
The whole sticker thing may be a supremely dumb waste of time and resources, but unconstitutional? If a case could be reasonably made that the book's wording miscategorizes evolution fact (observed speciation, etc.) with evolution theory, then there is no constitutional question here.
If you want:
1. Leaders who are actually somewhat accountable to YOU,
2. Leaders who actually represent YOU, and
3. To not be so horribly frustrated with democracy, then...
Do your RESEARCH and vote for your local officials in an informed manner. Many people are disenfranchised by the democratic process precisely because they only watch the news (which is only interested in big elections). The fact is that only your LOCAL leaders will, as a general rule, affect you personally. The likelihood that Bush or Kerry will impact you personally is basically zero. The likelihood that your Mayor, State Representatives, or local districtpeople will have a direct impact on you, your children, your neighbors, etc.
If you don't check a box for president, big deal. If you pick your local folks at random, on party lines, or because you like the sound of their name, you deserve what you get.
Start your research with whatever your Secretary of State sent you, or go online to e.g. http://www.smartvoter.org/ (CA and OH, mostly, others linked).
Seriously. Why not have something like this? For simple OS+apps, 10GB is still overkill (my main PC at home has only ~4GB used, and it'd be even less compressed). I don't even think SCSI is necessary--just put it on a PCI card and emulate an IDE bridge (fast) or use e.g. Serial ATA as an interface (slower, but more compatible).
For video and whatnot, sure. Use a conventional HD. But for OS and apps to be smokin' fast, battery-backed RAM is the way to go.