For what you describe, the solution is easy, a lot of BIOS allow console redirection through serial. Even if yours doesn't, linux kernel and getty can be easily configured to use serial as console, in the POST-BIOS sense, you need to do it even if the bios redirects console, as once linux loads that console redirection typically goes away. It is quite convenient for the sort of thing you describe.
That sounds really whack... There *is* a glut of unemployed decent developers, and that sounds like an exceedingly easy problem (especially in perl or python, hell, given an hour I'd get bored and slap a gui on it if wxPython or PyGTK were acceptable, just for the hell of it). I do believe that there are a *lot* of highly unqualified people who may look fine on paper but have no real skills, but not a single success?? Seems really off...
So you give an on the spot practical exam, give a hard deadline of 15 minutes for a series of problems, to someone who has enough pressure expecting a typical interview? And whose authority says the problems are together a 15 minute problem? Maybe they would be able to tackle them in under 15 minutes after getting into their groove. Giving a simple pass/fail evaluation of a 15 minute session of problems that are likely ill balanced, i.e. focused in one area. You could end up with a developer who can whip right through those, but turn out not to be well rounded.
What I have seen to be a better selector is strategies where the interviewer puts forth a problem that is technical and high-level in nature, and disallows use of a computer, and ask that the applicant think aloud about the strategy and algorithms they would try to accomplish the task. The interviewer then gets more information. For one, the circumstances are less stressful, so it is a better indication of typical performance. Also, whether or not they end up at the right solution is less important than if you can see they have a good thought process and good ability to recover from changing circumstances (in the middle of the problem, introduce new requirements).
I do agree that the dot-com crap created a lot of untalented, uninterested people seeking computer jobs simply for 'easy money' rather than a sincere passion, but knowing how very many talented developers I have seen unemployed over the last half a year, I would say either you aren't posting it in any visible spot or that your 15-minute test is a flawed approach.
Actually the strategy for bolting a frontend onto a cli program can work fine, but the common fallacy is that the developer would be lazy so they would just pass back what could be an error message rather than trying to parse it. Of course, in doing that the program gets tied into parsing output that, from the perspective of the CLI program, has no reason to stay perfectly the same, and may change if they think a certain sort of wording reflects the situation better, because the intended parsers (humans) are intelligent enough to interpolate the differences.
A more solid approach (which I adopt in any CLI programe I make), is to have a core entirely independent of whatever bit interfaces with the user, with simple library calls and well defined return codes. That way CLI and GUI are equal in terms of consistent interface to the core functionality. This is of course common sense and requires that the CLI program follow this strategy, but I have been in circumstances where I was faced with the need to write a GUI for something doable from the command line, and if I'm not pressed for time and the CLI program is open source, I will libify it before writing my gui.
As far as 'The UNIX crowd will never get this right', that is just ridiculous, a *lot* of circumstances 'get this right', xine does it, mplayer in its next generation is doing it. You find that any significant project seems to end up down this path, and it is a good thing. And to complain about 'all of those stupid files in/etc' is just ludicrous, it works fine and I would say much better than the win32 registry, and I don't see too much special about netinfo db either, the implementation of settings management does not have to be user visible for the less technical crowd, and the/etc approach is friendly to power users that understand things on a lower level.
I would dare say Sun may no longer qualify, and if so, than Apple would qualify. Also, breaking things up by company may not be correct. I can bet large groups within HP/Compaq do not use MS on the desktop (HP-UX/Linux groups), and now that IBM's general policy in many areas is 'what ever works best for you', and in many cases that is linux. If you want to call RedHat or SuSE a large company, there is another. And I'd wager a large number of Novell's desktops are linux (a validation of their current strategy after all).
I believe the complaint is that the strategy seems to be this: 1) Release relatively unstable package of all sorts of things. 2) Technical users fix problems for own use, submit patches into the project. 3) Both RHEL and Fedora pick up patches. However, when the patches get distributed with a new Fedora, they will tack on enough other, unstable software to offset the stability of provided patches.
I can certainly believe that if Red Hat continues to truly hold the reigns of Fedora from behind the scenes, that they will have a vested interest in keeping things a tad too far into the bleeding edge for it to be useable by a majority of users, and having paths to stability require a lot of end-user effort/ability to ensure the 'value-add' of the Enterprise editions is perceived as worth the added cost.
I really don't understand this, RAID costs $0 when done in software. Just because you get high MTBF doesn't mean a freak accident won't trash your data, RAID is really worth losing even 1/4 to 1/2 of you space in exchange. It may not be perfect, but it is a great first line of defense against failure.
The answer is simple, simply reroute the EPS conduit to discharge antimatter through the deflector dish, and possibly adjust the Heisenberg compensator for the occasion.
Interesting on the HDTV resolutions, though I wonder how it is handled, I would think just bumping up the resolution would mess with games developed for and tested on NTSC level resolution, things would slow down for games that really push it.....
Now, as to the strategy proposed for getting 60 fps, I doubt that the XBox would expose this sort of feature, simply because it would be a rather more significant design chnage for TV-out over the desktop models, and I understand they wanted to keep R&D for the venture down. However, presuming that they *do* expose a method to rendering to the even and odd scanlines of a 'single' NTSC full frame separately, that leaves only 240 lines of resolution to work with (now we are talking Wolf3D/Doom resolutions). The resulting jaggedness of any given frame of the screen would more than offset motion smoothness, and putting that aside, you have again greatly reduced the complexity of the render task, so 60 fps should be a breeze.
Of course, even after taking all this into account, the simple fact of the matter is that a PC version of a game is likely to pull out more bells and whistles to take advantage of the more sophisticated hardware, so even if the X-Box and PC were playing on equal ground graphics complexity-wise, the PC version would be more demanding because the developers' know the platform is more accomodating.
Easy. Nothe that for one, the resolution is 1280x1024. Now I'm not sure what would be the XBOX render output, but I would wager that at *most* it is 800x600, and likely to be 640x480. If 640x480, the render area is over 4x as detailed as the XBOX output. Color depth also could be different.
Secondly, the goal for the TV output is probably ~30 fps, beyond that and you are throwing out frames (well, 29.97 to be more precise on NTSC). Note by this goal, 1600x1200 (4 times the area of even 800x600), is attainable, give or take a couple of FPS.
I would think it would take training to get the thing to work the way you want it, I imagine accidently making a robotic arm do something as complex as that is at least as unlikely as accidently doing it with a natural arm.
1. Mine has the lock feature to prevent this, very handy. 2. Mine is fine, though I have the old iPod. 3. Yeah, that sucks in my opinion too, I would prefer a more transparent access to the device. 4. That annoys me as well, though I would say some people organize things better by ID3 tags, and admittedly there *is* more flexiblity in ways to organize and find songs when there are more fields to go by. For me on a system it was easier to organize by folders and the ID3 tags were a waste of time to worry about, so it really hurts transferring. 5. Could stand to be longer, but hasn't been too much of an issue to me. You make an analogy indicating cell phones last a long time and iPod's don't reflect this. But if you constantly use a cell phone, it won't last a full day either. Similarly, if I leave the iPod paused a lot, it lasts days too. 6. I'll assume you're right, and that really does suck. 7. That damned remote annoys the hell out of me too. I have no idea where it was intended to be clipped and used, it is inconvenient everywhere. I finally settled on clipping it on one of my front pants pocket with iPod inside that pocket, headphone jack facing back, which is strange to me, and the controls feel backward.
And I'll add another complaint, the neat little holder/belt clip is nice and all, but it is so damn flimsy, and mine broke long ago. This seems to be a trend to me with respect to Apple hardware, it is all nice looking, but flimsy as hell on the external components. Plastic headphone jacks annoy me (iPod sadly has this too), and, in general, a *lot* of fragile plastic is used in making iBooks.
At least know the proper NAT ranges! I've seen even professionals *extremely* misguided that 192.0.0.0/8 and 10.0.0.0/8 are the two NAT networks. They aren't, well, 10.0.0.0/8 is. Again, the private subnets are: 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12
Don't use outside that range! I've seen stuff *ship* with what is obviously meant to be a private net address that was outside the range because the manufacturer didn't know the netmasks...
If you *had* a holodeck, you would feasibly use it to simulate sitting at a computer posting to slashdot? That's pretty lame, there are far more interesting things that could be done with a holodeck.
How many people write faster than they can type, *especially* when they have to write such that the computer can understand what was written? It is hard enough for me to write with the expectation that another human will be able to decipher it, a computer, forget it.
The only advantage is for diagrams, and ultimately, there are far better ways of doing that even, back of a napkin, notebook, whiteboard, even touchpads provide 'good enough' capability for things like teleconferencing, why in the world would someone want a tablet?
I think he was indicating that the reliability of RAID-1 IDE drives is at least on par with SCSI but still cheaper byte for byte.
But, you are only half right. RAID-1 will make writes to the filesystem slower, but RAID-1, if implemented decently, could almost always beat out RAID-0 for speed. With RAID-0, when two random read requests are issued, there is a 50% chance they are on the same device (in the two device case), with RAID-1, 100% of the time you can one block from one device at the same time you get a block from another. Maybe there is a penalty in sequential reads, because in RAID1, the devices would be skipping every other sector and still have to bear the rotational penalty of the sectors being non-sequential. I guess ultimately, with almost all things, it depends on the implementation and the situation.
AIST is getting a similar scale Linux cluster using Opteron processors, a bit larger (are all the G5 dual proc boxes? If so things are still in the same ball park). about 1100 dual opteron systems, and a few other Intel boxes tossed in. One good article is here.
I have submitted this as story, but it evidently never news like the G5 cluster... Linux and AMD no longer our favorite 'underdogs' anymore?
At that point Google would be a really bad guy. Sorting by *anything* but a good faith analysis of how the content is relevant to the search terms is bad. I don't care if it is to advertise subvertly, or to push an agenda (sorting by things that break IE/only presenting things that work perfectly with Google's browser of choice). The agenda in this case may be one I agree with, but it doesn't make it right. Google is one of the few internet success stories that really does the right thing consistantly, and I'd like to see it kept that way.
Slashdot Mirror
Sounds kinda like Cher's song of late.. A few samples with no range, no expression... yep.... already there.
And while you are at it, put in some AIs to listen and watch the crap...
For what you describe, the solution is easy, a lot of BIOS allow console redirection through serial. Even if yours doesn't, linux kernel and getty can be easily configured to use serial as console, in the POST-BIOS sense, you need to do it even if the bios redirects console, as once linux loads that console redirection typically goes away. It is quite convenient for the sort of thing you describe.
That sounds really whack... There *is* a glut of unemployed decent developers, and that sounds like an exceedingly easy problem (especially in perl or python, hell, given an hour I'd get bored and slap a gui on it if wxPython or PyGTK were acceptable, just for the hell of it). I do believe that there are a *lot* of highly unqualified people who may look fine on paper but have no real skills, but not a single success?? Seems really off...
So you give an on the spot practical exam, give a hard deadline of 15 minutes for a series of problems, to someone who has enough pressure expecting a typical interview? And whose authority says the problems are together a 15 minute problem? Maybe they would be able to tackle them in under 15 minutes after getting into their groove. Giving a simple pass/fail evaluation of a 15 minute session of problems that are likely ill balanced, i.e. focused in one area. You could end up with a developer who can whip right through those, but turn out not to be well rounded.
What I have seen to be a better selector is strategies where the interviewer puts forth a problem that is technical and high-level in nature, and disallows use of a computer, and ask that the applicant think aloud about the strategy and algorithms they would try to accomplish the task. The interviewer then gets more information. For one, the circumstances are less stressful, so it is a better indication of typical performance.
Also, whether or not they end up at the right solution is less important than if you can see they have a good thought process and good ability to recover from changing circumstances (in the middle of the problem, introduce new requirements).
I do agree that the dot-com crap created a lot of untalented, uninterested people seeking computer jobs simply for 'easy money' rather than a sincere passion, but knowing how very many talented developers I have seen unemployed over the last half a year, I would say either you aren't posting it in any visible spot or that your 15-minute test is a flawed approach.
Some companies have product roadmaps, SCO publishes lawsuit roadmaps... I guess that *is* SCO's sole product nowadays.
Actually the strategy for bolting a frontend onto a cli program can work fine, but the common fallacy is that the developer would be lazy so they would just pass back what could be an error message rather than trying to parse it. Of course, in doing that the program gets tied into parsing output that, from the perspective of the CLI program, has no reason to stay perfectly the same, and may change if they think a certain sort of wording reflects the situation better, because the intended parsers (humans) are intelligent enough to interpolate the differences.
/etc' is just ludicrous, it works fine and I would say much better than the win32 registry, and I don't see too much special about netinfo db either, the implementation of settings management does not have to be user visible for the less technical crowd, and the /etc approach is friendly to power users that understand things on a lower level.
A more solid approach (which I adopt in any CLI programe I make), is to have a core entirely independent of whatever bit interfaces with the user, with simple library calls and well defined return codes. That way CLI and GUI are equal in terms of consistent interface to the core functionality. This is of course common sense and requires that the CLI program follow this strategy, but I have been in circumstances where I was faced with the need to write a GUI for something doable from the command line, and if I'm not pressed for time and the CLI program is open source, I will libify it before writing my gui.
As far as 'The UNIX crowd will never get this right', that is just ridiculous, a *lot* of circumstances 'get this right', xine does it, mplayer in its next generation is doing it. You find that any significant project seems to end up down this path, and it is a good thing. And to complain about 'all of those stupid files in
I would dare say Sun may no longer qualify, and if so, than Apple would qualify. Also, breaking things up by company may not be correct. I can bet large groups within HP/Compaq do not use MS on the desktop (HP-UX/Linux groups), and now that IBM's general policy in many areas is 'what ever works best for you', and in many cases that is linux. If you want to call RedHat or SuSE a large company, there is another. And I'd wager a large number of Novell's desktops are linux (a validation of their current strategy after all).
But I would say 750GB of single drive fault tolerant storage is much better than 1TB of storage that could all get screwed up by a single failure.
I believe the complaint is that the strategy seems to be this:
1) Release relatively unstable package of all sorts of things.
2) Technical users fix problems for own use, submit patches into the project.
3) Both RHEL and Fedora pick up patches. However, when the patches get distributed with a new Fedora, they will tack on enough other, unstable software to offset the stability of provided patches.
I can certainly believe that if Red Hat continues to truly hold the reigns of Fedora from behind the scenes, that they will have a vested interest in keeping things a tad too far into the bleeding edge for it to be useable by a majority of users, and having paths to stability require a lot of end-user effort/ability to ensure the 'value-add' of the Enterprise editions is perceived as worth the added cost.
I wouldn't say emulation is necessary, only virtualization (ala VMWare).
I really don't understand this, RAID costs $0 when done in software. Just because you get high MTBF doesn't mean a freak accident won't trash your data, RAID is really worth losing even 1/4 to 1/2 of you space in exchange. It may not be perfect, but it is a great first line of defense against failure.
See the words 'amateur' and 'penetrate' in close proximity and, well, thought something entirely different?
The answer is simple, simply reroute the EPS conduit to discharge antimatter through the deflector dish, and possibly adjust the Heisenberg compensator for the occasion.
Interesting on the HDTV resolutions, though I wonder how it is handled, I would think just bumping up the resolution would mess with games developed for and tested on NTSC level resolution, things would slow down for games that really push it.....
Now, as to the strategy proposed for getting 60 fps, I doubt that the XBox would expose this sort of feature, simply because it would be a rather more significant design chnage for TV-out over the desktop models, and I understand they wanted to keep R&D for the venture down. However, presuming that they *do* expose a method to rendering to the even and odd scanlines of a 'single' NTSC full frame separately, that leaves only 240 lines of resolution to work with (now we are talking Wolf3D/Doom resolutions). The resulting jaggedness of any given frame of the screen would more than offset motion smoothness, and putting that aside, you have again greatly reduced the complexity of the render task, so 60 fps should be a breeze.
Of course, even after taking all this into account, the simple fact of the matter is that a PC version of a game is likely to pull out more bells and whistles to take advantage of the more sophisticated hardware, so even if the X-Box and PC were playing on equal ground graphics complexity-wise, the PC version would be more demanding because the developers' know the platform is more accomodating.
Easy. Nothe that for one, the resolution is 1280x1024. Now I'm not sure what would be the XBOX render output, but I would wager that at *most* it is 800x600, and likely to be 640x480. If 640x480, the render area is over 4x as detailed as the XBOX output. Color depth also could be different.
Secondly, the goal for the TV output is probably ~30 fps, beyond that and you are throwing out frames (well, 29.97 to be more precise on NTSC). Note by this goal, 1600x1200 (4 times the area of even 800x600), is attainable, give or take a couple of FPS.
I would think it would take training to get the thing to work the way you want it, I imagine accidently making a robotic arm do something as complex as that is at least as unlikely as accidently doing it with a natural arm.
1. Mine has the lock feature to prevent this, very handy.
2. Mine is fine, though I have the old iPod.
3. Yeah, that sucks in my opinion too, I would prefer a more transparent access to the device.
4. That annoys me as well, though I would say some people organize things better by ID3 tags, and admittedly there *is* more flexiblity in ways to organize and find songs when there are more fields to go by. For me on a system it was easier to organize by folders and the ID3 tags were a waste of time to worry about, so it really hurts transferring.
5. Could stand to be longer, but hasn't been too much of an issue to me. You make an analogy indicating cell phones last a long time and iPod's don't reflect this. But if you constantly use a cell phone, it won't last a full day either. Similarly, if I leave the iPod paused a lot, it lasts days too.
6. I'll assume you're right, and that really does suck.
7. That damned remote annoys the hell out of me too. I have no idea where it was intended to be clipped and used, it is inconvenient everywhere. I finally settled on clipping it on one of my front pants pocket with iPod inside that pocket, headphone jack facing back, which is strange to me, and the controls feel backward.
And I'll add another complaint, the neat little holder/belt clip is nice and all, but it is so damn flimsy, and mine broke long ago. This seems to be a trend to me with respect to Apple hardware, it is all nice looking, but flimsy as hell on the external components. Plastic headphone jacks annoy me (iPod sadly has this too), and, in general, a *lot* of fragile plastic is used in making iBooks.
At least know the proper NAT ranges! I've seen even professionals *extremely* misguided that 192.0.0.0/8 and 10.0.0.0/8 are the two NAT networks. They aren't, well, 10.0.0.0/8 is. Again, the private subnets are:
10.0.0.0/8
192.168.0.0/16
172.16.0.0/12
Don't use outside that range! I've seen stuff *ship* with what is obviously meant to be a private net address that was outside the range because the manufacturer didn't know the netmasks...
If you *had* a holodeck, you would feasibly use it to simulate sitting at a computer posting to slashdot? That's pretty lame, there are far more interesting things that could be done with a holodeck.
How many people write faster than they can type, *especially* when they have to write such that the computer can understand what was written? It is hard enough for me to write with the expectation that another human will be able to decipher it, a computer, forget it.
The only advantage is for diagrams, and ultimately, there are far better ways of doing that even, back of a napkin, notebook, whiteboard, even touchpads provide 'good enough' capability for things like teleconferencing, why in the world would someone want a tablet?
I think he was indicating that the reliability of RAID-1 IDE drives is at least on par with SCSI but still cheaper byte for byte.
But, you are only half right. RAID-1 will make writes to the filesystem slower, but RAID-1, if implemented decently, could almost always beat out RAID-0 for speed. With RAID-0, when two random read requests are issued, there is a 50% chance they are on the same device (in the two device case), with RAID-1, 100% of the time you can one block from one device at the same time you get a block from another. Maybe there is a penalty in sequential reads, because in RAID1, the devices would be skipping every other sector and still have to bear the rotational penalty of the sectors being non-sequential. I guess ultimately, with almost all things, it depends on the implementation and the situation.
AIST is getting a similar scale Linux cluster using Opteron processors, a bit larger (are all the G5 dual proc boxes? If so things are still in the same ball park). about 1100 dual opteron systems, and a few other Intel boxes tossed in. One good article is here.
I have submitted this as story, but it evidently never news like the G5 cluster... Linux and AMD no longer our favorite 'underdogs' anymore?
At that point Google would be a really bad guy. Sorting by *anything* but a good faith analysis of how the content is relevant to the search terms is bad. I don't care if it is to advertise subvertly, or to push an agenda (sorting by things that break IE/only presenting things that work perfectly with Google's browser of choice). The agenda in this case may be one I agree with, but it doesn't make it right. Google is one of the few internet success stories that really does the right thing consistantly, and I'd like to see it kept that way.
You're wrong ;)
Quicktime is at least one example...