And that's with the inclusion of several sets of textures geared for different amounts of VRAM.
This is off-topic and a nitpick, but I just needed to get it out because I've seen this "several sets of textures" line before. Those "extra" textures aren't actually "extra": you have them around anyway to do mipmapping, for when the texture is far away and small on-screen. Console games have them too.
Except that OP was wrong. The problem in the diagrams was not lack of precision but instead a broken complex type.
Re:Good for Apply Maybe, good for Palm - NO!
on
Apple to Buy out Palm?
·
· Score: 4, Informative
As for rewriting in Linux - does that mean their current Palm OS is such a dead end that they can't evolve it?
Yes. I've developed for it before, and it's got cruft coming out of its ears.
That's true for Palm OS 4. Palm OS Garnet (the first version of the ARM OS) lifts a few of those restrictions, but it's still pretty much a hack.
But PalmSource has been working on Palm OS Cobalt, their next gen OS, for the last few years. They actually had a preview ready at the Palm Developers' Conference I attended in 2004: it has next-gen databases with a built in sql-like query language, next gen PIM applications, threading, real process separation, berkeley socket networking, well-thought-out security model, etc. It is a Real OS.
You've been able to get an emulator and tool suite since that conference: if you want, you could develop a new Cobalt app today.
The problem? No hardware. Since PalmSource didn't have a hardware division anymore, they couldn't force anybody to actually use the OS, and Palm opted short-sightedly to stick with Garnet.
Thus, the move to Linux, to make the platform more attractive to phone manufacturers. But keep in mind it's just the underlying kernel that's Linux: on top, everything is Cobalt, both to the user and the developer. The advantage is that phone makers can reuse more of their existing software infrastructure (drivers, etc.) if they've been developing Linux phones.
Not too expensive, they have good low-end, they're pretty comfortable, and you really can hear through them. The only real problem I have is the headband tends to collapse when I take them off, and sometimes my hair gets caught in there (ow). Also they're not the sturdiest headphones ever, but hey, they're made to be light and portable.
What I'd really like is to sneak one of these in the top tube of my bike... and never worry about it getting stolen again. It might disappear for a day, but then I'd be able to give the police a solid lead on the assholes that took it: yum.
I might wait until the device costs less than my bike did, though.
Okay, after some more searching I found a few better deals, around $75. Still, it's not like $51 is above retail prices. It's still a healthy discount.
If Microsoft is really paying $51 for a quality 20GB hard drive, then they need their heads checked.
Bear in mind that this isn't a plain ATA desktop hard disk, it's a laptop-format SATA drive. Right now those cost like $400 at retail. $51 sounds very reasonable to me.
No, I have it the right way around. I think you're confused about what I'm saying; I'm saying that as voltage drops (and current increases), the wire has to be thicker to reduce resistive loss. I'm not saying anything about insulation.
Also, you have Ohm's law backwards: 1 amp at 1 volt = 1 watt. Which is bizarre because you otherwise sound like you know what you're talking about.
Wouldn't it be so much easier if there was some sort of standard wall wart power supply with a standard connector?
As has been suggested already... if you can use a standard power converter, why not skip the converter and run off a standard DC supply voltage?
And the answer to that is, different circuits need different supply voltages. It's not practical to make all electronics run off the same supply, and it's no harder to make an AC->DC converter than it is to make a DC->DC converter; in fact it's simpler, especially if you want to convert from a low voltage to a high voltage.
There are also good reasons to keep the supply voltage high: reducing the supply voltage means you need thicker wires in your outlets and power cables, and that costs money. Transitioning to a different standard would also cost money.
This still doesn't really explain why we have wall-warts though. It's possible to put power supplies inside electronics, even tiny devices like broadband routers.
Why don't they? Well, there's a safety issue. Line voltage is dangerous, and if you build a power supply into a piece of electronics you have to be very careful about isolating the dangerous voltages from the person using the device. So they'd need to pay to design that power supply (and make it safe), and they'd need to pay the tooling costs to manufacture the custom built-in power supply.
Repackaging a bog-standard wall wart is probably cheaper and certainly less risky.
Basically, the status quo isn't quite as silly as it may at first appear. There are alternatives, but they all have problems too, and the cost of the transition probably just wouldn't be worth it.
Colonists are more likely to settle near equator due to temperature
Sounds dubious to me. The lunar day is about a month long, so they'll get a couple weeks of sun and warmth at the equator, sure... then another couple weeks of pitch-black and freezing temperatures.
At the poles you get constant sunlight, which seems like a win, even though it's always coming in at a shallow angle.
Well, there is the fact that Canada has a significantly larger population than Australia: 31M vs. 20M, by the latest census data. So... why put Australia but not Canada on the list of major english-speaking countries?
Of course if we just go by english-speaking populations, I think South Africa has as many english-speakers as Australia, and India probably has as many as the rest of the world put together.
If you can't do basic analysis (which might require some rudamentary calc) then you won't be able to model (and thus justify) any algorithmic choices you make as a project manager.
That's a little black-and-white... a few rules of thumb and simple reasoning can give you a pretty good idea of the performance class of most algorithms. And you can always run the algorithm and measure its performance.
In fact you have to do this anyway, because things like cache effectiveness, memory bandwidth, disk bandwidth and seek times, scheduling, and so on will have unexpected impacts on performance even if you do a thorough analysis.
There might be other reasons for why Linux is a better platform for streaming, playing, recording, or encoding video. But I doubt this is it. Real-time OS's are aimed at embedded applications, usually systems that combine both external hardware and software...
Two things. First, low latency at the expense of a little throughput is actually quite important for pro audio recording, and especially for applications like software synthesizers; it really sucks when there's a half-second delay between twiddling a knob or pressing a key and hearing the effect that has.
Second, there's a much better reason that RTLinux is irrelevant, even to the pro audio stuff that wants a real-time kernel: real-time processes in RTLinux can't access the Linux kernel, they can only access the RTLinux core. This means they would need special drivers for audio, MIDI, and so on, and any access to the file system or any other normal OS or userland service would have to go through a pipe to a non-realtime server -- super annoying.
This is why Linux audio developers are still pushing for at least soft-realtime performance in the stock kernel. RTLinux is good at what it does, but it's really only practical for systems that are deployed on limited hardware, such as telecoms systems and other embedded systems, where the appropriate drivers can be built into the application.
I know it make no sense in the real world, but would you rather get to begin your career on a lower rung because you choose the most appropriate curriculum for your career path ? For most people, the answer is no, thus we are collectively trying to retrofit computer "scientists" into programming roles.
I couldn't have said it better. It's amazing to me how many people will defend the value of a CS degree as a preparation for software engineering, but it hardly makes sense.
All the rest of the engineering disciplines, which are actually pretty similar to software engineering, have focused bachelors-level programs and have for decades. They still learn the scientific underpinnings of their disciplines, but they are also trained in the less glamorous things they'll need to do on the job, such as estimation and documentation, things that CS grads fresh from school are typically not very good at at all.
You're assuming tusklessness is a genetic trait -- how do you know for sure that it is? Maybe tuskless elephants are just as likely to have tusked offspring as tusked elephants. Not that this is likely, but let's rule out the wacky-but-possible first.
Now here's the trick, you can't just say that tusklessness is passed on genetically because of the rise of tuskless elephants. As GP was pointing out, you get an increase in the incidence of tusklessness if you cull tusked elephants, even if it's not genetic. By itself the increase proves nothing; you have to do some statistics to figure out whether it's a genetically determined trait or just random.
So it takes an integer operation 15 or so cycles to be complete in an Athlon, and 30 cycles in a P4. Thus the higher IPC.
I don't know if you really are a computer engineer (if you are you're probably not a very good one), but that's just bad logic. The whole point of a pipeline is that although a single instruction takes as many cycles to get through as there are stages, you can also have that many instructions in the pipeline at once. So, as long as your pipeline stays full (which is another discussion entirely), you still execute one instruction per cycle, no matter how long the pipeline is.
Imagine an assembly line that's making cars. You don't wait until the first car gets off the end of the line before you start making the next one!
IMO if the case you presented were to occur, then why not?
The way you've defined a soul, a computer has a soul. I agree with you -- I subscribe to the "brain as a computer" school of thought -- but I do recognize that a stricly biological definition of the word "soul" is useless. We already have a perfectly good word for the biological item in question, "brain". We don't need "soul" to mean just "brain" or "living brain".
...in a lot of cases (not all of course) it makes sense to get rid of the highest paid people. If you've been there for 10 years, not only are you normally get paid more then other people, you also get more time off, and require more severance pay.
What you are saying by that is that people with more experience are overpaid.
Sometimes that's true. But don't you think that it makes more sense for the company to offer a pay cut as an alternative to the layoff first? (Or even better, don't give them a raise you can't afford in the first place!)
Particularly if this is a valuable, loyal employee that they just can't afford anymore. By keeping them on, the company would save on hiring, training, and that severance package, all of which are big costs. Consider also that they'll probably have to go through a few good-on-paper-only candidates before finding someone really effective... it's just a waste, it's not by any stretch the most efficient way to operate
Indeed. I get a very strong impression that he hasn't actually touched the development tools -- he admits to not even having heard the sound in HL2 at all! -- he's just guessing at what the engines can do based on the games. For example, he downplays Doom's physics engine quite a bit, saying that although it has many of the same features, it's "on a smaller scale". Newsflash, the features are all that matters! The fact that the D3 level designers didn't use their physics engine as much as HL2 designers used theirs only tells you they didn't want that gameplay style.
Slashdot Mirror
This is off-topic and a nitpick, but I just needed to get it out because I've seen this "several sets of textures" line before. Those "extra" textures aren't actually "extra": you have them around anyway to do mipmapping, for when the texture is far away and small on-screen. Console games have them too.
Except that OP was wrong. The problem in the diagrams was not lack of precision but instead a broken complex type.
But PalmSource has been working on Palm OS Cobalt, their next gen OS, for the last few years. They actually had a preview ready at the Palm Developers' Conference I attended in 2004: it has next-gen databases with a built in sql-like query language, next gen PIM applications, threading, real process separation, berkeley socket networking, well-thought-out security model, etc. It is a Real OS.
You've been able to get an emulator and tool suite since that conference: if you want, you could develop a new Cobalt app today.
The problem? No hardware. Since PalmSource didn't have a hardware division anymore, they couldn't force anybody to actually use the OS, and Palm opted short-sightedly to stick with Garnet.
Thus, the move to Linux, to make the platform more attractive to phone manufacturers. But keep in mind it's just the underlying kernel that's Linux: on top, everything is Cobalt, both to the user and the developer. The advantage is that phone makers can reuse more of their existing software infrastructure (drivers, etc.) if they've been developing Linux phones.
Not too expensive, they have good low-end, they're pretty comfortable, and you really can hear through them. The only real problem I have is the headband tends to collapse when I take them off, and sometimes my hair gets caught in there (ow). Also they're not the sturdiest headphones ever, but hey, they're made to be light and portable.
Sounds practical to me! =D
What I'd really like is to sneak one of these in the top tube of my bike... and never worry about it getting stolen again. It might disappear for a day, but then I'd be able to give the police a solid lead on the assholes that took it: yum.
I might wait until the device costs less than my bike did, though.
Okay, after some more searching I found a few better deals, around $75. Still, it's not like $51 is above retail prices. It's still a healthy discount.
Bear in mind that this isn't a plain ATA desktop hard disk, it's a laptop-format SATA drive. Right now those cost like $400 at retail. $51 sounds very reasonable to me.
No, I have it the right way around. I think you're confused about what I'm saying; I'm saying that as voltage drops (and current increases), the wire has to be thicker to reduce resistive loss. I'm not saying anything about insulation.
Also, you have Ohm's law backwards: 1 amp at 1 volt = 1 watt. Which is bizarre because you otherwise sound like you know what you're talking about.
And the answer to that is, different circuits need different supply voltages. It's not practical to make all electronics run off the same supply, and it's no harder to make an AC->DC converter than it is to make a DC->DC converter; in fact it's simpler, especially if you want to convert from a low voltage to a high voltage.
There are also good reasons to keep the supply voltage high: reducing the supply voltage means you need thicker wires in your outlets and power cables, and that costs money. Transitioning to a different standard would also cost money.
This still doesn't really explain why we have wall-warts though. It's possible to put power supplies inside electronics, even tiny devices like broadband routers.
Why don't they? Well, there's a safety issue. Line voltage is dangerous, and if you build a power supply into a piece of electronics you have to be very careful about isolating the dangerous voltages from the person using the device. So they'd need to pay to design that power supply (and make it safe), and they'd need to pay the tooling costs to manufacture the custom built-in power supply.
Repackaging a bog-standard wall wart is probably cheaper and certainly less risky.
Basically, the status quo isn't quite as silly as it may at first appear. There are alternatives, but they all have problems too, and the cost of the transition probably just wouldn't be worth it.
At the poles you get constant sunlight, which seems like a win, even though it's always coming in at a shallow angle.
I mean, we are routing packets and not wood here, right?
Of course if we just go by english-speaking populations, I think South Africa has as many english-speakers as Australia, and India probably has as many as the rest of the world put together.
In fact you have to do this anyway, because things like cache effectiveness, memory bandwidth, disk bandwidth and seek times, scheduling, and so on will have unexpected impacts on performance even if you do a thorough analysis.
Second, there's a much better reason that RTLinux is irrelevant, even to the pro audio stuff that wants a real-time kernel: real-time processes in RTLinux can't access the Linux kernel, they can only access the RTLinux core. This means they would need special drivers for audio, MIDI, and so on, and any access to the file system or any other normal OS or userland service would have to go through a pipe to a non-realtime server -- super annoying.
This is why Linux audio developers are still pushing for at least soft-realtime performance in the stock kernel. RTLinux is good at what it does, but it's really only practical for systems that are deployed on limited hardware, such as telecoms systems and other embedded systems, where the appropriate drivers can be built into the application.
All the rest of the engineering disciplines, which are actually pretty similar to software engineering, have focused bachelors-level programs and have for decades. They still learn the scientific underpinnings of their disciplines, but they are also trained in the less glamorous things they'll need to do on the job, such as estimation and documentation, things that CS grads fresh from school are typically not very good at at all.
So why not software engineering too?
You're missing the point.
You're assuming tusklessness is a genetic trait -- how do you know for sure that it is? Maybe tuskless elephants are just as likely to have tusked offspring as tusked elephants. Not that this is likely, but let's rule out the wacky-but-possible first.
Now here's the trick, you can't just say that tusklessness is passed on genetically because of the rise of tuskless elephants. As GP was pointing out, you get an increase in the incidence of tusklessness if you cull tusked elephants, even if it's not genetic. By itself the increase proves nothing; you have to do some statistics to figure out whether it's a genetically determined trait or just random.
Imagine an assembly line that's making cars. You don't wait until the first car gets off the end of the line before you start making the next one!
The way you've defined a soul, a computer has a soul. I agree with you -- I subscribe to the "brain as a computer" school of thought -- but I do recognize that a stricly biological definition of the word "soul" is useless. We already have a perfectly good word for the biological item in question, "brain". We don't need "soul" to mean just "brain" or "living brain".
Safari is both OSS and commercial.
What you are saying by that is that people with more experience are overpaid.
Sometimes that's true. But don't you think that it makes more sense for the company to offer a pay cut as an alternative to the layoff first? (Or even better, don't give them a raise you can't afford in the first place!)
Particularly if this is a valuable, loyal employee that they just can't afford anymore. By keeping them on, the company would save on hiring, training, and that severance package, all of which are big costs. Consider also that they'll probably have to go through a few good-on-paper-only candidates before finding someone really effective... it's just a waste, it's not by any stretch the most efficient way to operate