Yes. The first bit of a sigmoid growth function looks a lot like an exponential growth function. In the real world, when you have exponential growth in anything, you eventually get a sigmoid if you're lucky and a crash if not.
You're simply wrong.
It's an enormous advance in usability over competing phones. I've been using computers since 1979. I'm a professional software developer. I am not afraid of complexity. I'm not afraid of command line interfaces. I'm not a luddite. I'm not a grandpa.
Every cell phone I've ever used has freaked me out completely. My previous cell phone, I never bothered to use the address book because it was too awkward to navigate the UI to it. Even my most frequent contact, my wife, whose office and cell phone were in a different area code, I would enter the number anew on the keypad every time because I couldn't deal with the UI.
the hard drive (you get to choose slow or obscenely expensive)
Given what you're going to use the Air for, what's the problem with a slow hard disk? I mean, it's not going to affect word processing, spreadsheeting, or web surfing noticeably. Slightly longer boot times? This isn't a suitable machine for doing media creation and editing on, period. I think it's a reasonable compromise.
I'm a "all I do is code" type and I've written some truely amazing code which works quickly, efficiently and is used on hundreds of different high traffic websites. I have yet to find someone who can understand what it does and how it does it. Its voodoo to everyone.
You're fired.
If you aren't writing clear and understandable code, I don't want you on my project.
The PPC core in the PS3 is pretty basic, executes only in-order, and can probably be outperformed by a Core 2 at 2.4GHz. You wouldn't gain anything by going PPC/Cell instead of Intel/Cell, and you'd lose Windows compatibility.
The PS3 doesn't run Linux; the development tools provided by Sony are Linux-based. This is a common misconception dating back from the PS2 days. "Cell" isn't really the PPC core anyway, and the PPC CPU in the PS3 is outperformed by any current Intel offering.
The Product Briefing you link is very vague as to what the "firmware framework" actually contains:
"PortalPlayer(TM) supports the PP5022 with an embedded firmware framework and FDK that includes robust development tools enabling custom feature sets and enhancements. The FDK allows developers to rapidly create differentiated platforms based on a complete suite of
standard functions, database engines, codecs, etc."
I'd be very surprised if they offer any firmware with functionality at a higher level than, e.g., block DCT. Do you have any evidence to the contrary?
Apple, however, deliberately designed the iPod's software so that it would only play a single protected digital format, Apple's FairPlay-modified AAC format
Microsoft deliberately designed their Windows software so that it can only run a single executable program format, their so-called Portable Executable format. Clearly the Intel CPU on a Windows PC can run Mac OSX apps and Linux apps. Can I sue Microsoft for not implementing the ability to run OSX and Linux apps?
Is there any labeling requirement for HD/BD releases to tell which codec they're using? If there's no guarantee that HD/BD is going to use a modern codec, I think I'm going to continue to buy movies off the iTunes store, since I can assume they're going to be using H.264.
The J58 was unique in that it was a hybrid jet engine. It could operate as a regular turbojet at low speeds, but at high speeds it became a ramjet. The engine can be thought of as a turbojet engine inside a ramjet engine. At lower speeds, the turbojet provided most of the compression and most of the energy from fuel combustion. At higher speeds, the turbojet throttled back and just sat in the middle of the engine as air bypassed around it, having been compressed by the shock cones and only burning fuel in the afterburner.
Game and engine development has happened concurrently on every game I've worked on. Even when you start with an existing engine, because the designers always want more more more more more, and last year you didn't accomplish all the awesome cool things you set out to put in the engine, so this year you're going to do it, and you're going to do it right.
Then the lead engineer gets hit by a twinkie truck, one of the designers gets stabbed with an icicle, one programmer is out for a while because she's donating a kidney to her best friend, another programmer isn't getting any work done because he's going through a divorce, and a third is writing crap code because he isn't getting any sleep because he and his wife just had twins, and in the end it's all you can do to make the engine limp along just well enough to ship another game and make payroll and try and stay afloat long enough to try to do it better next year.
We pack multiple characters' resources together into larger load units to avoid the overhead of small reads broken up by disk seeks (console optical disks really suck at the seek). We can't load and unload a character at a time, as a general rule, and by making the common memory area dynamic, you open yourself up to fragmentation and make it impossible to predict at runtime whether you'll have enough memory to load the common resources you need after a given sequence of region-to-region moves in the game.
There are a lot of smart suggestions being made in this thread. There have been a lot of smart suggestions made in the corridors and cubicles of game companies for the last ten years, too.
Actually, memory management for third party libraries is mostly a tractable problem now -- the good ones have memory allocation hooks, so you can give them small private memory arenas that won't create fragmentation in other memory spaces. But that's more engine complexity for you.
Slashdot Mirror
Yes. The first bit of a sigmoid growth function looks a lot like an exponential growth function. In the real world, when you have exponential growth in anything, you eventually get a sigmoid if you're lucky and a crash if not.
Users can go buy another smartphone, then. Door's to your left.
You're simply wrong. It's an enormous advance in usability over competing phones. I've been using computers since 1979. I'm a professional software developer. I am not afraid of complexity. I'm not afraid of command line interfaces. I'm not a luddite. I'm not a grandpa. Every cell phone I've ever used has freaked me out completely. My previous cell phone, I never bothered to use the address book because it was too awkward to navigate the UI to it. Even my most frequent contact, my wife, whose office and cell phone were in a different area code, I would enter the number anew on the keypad every time because I couldn't deal with the UI.
I'm sorry, who exactly forced you to update the software on your phone?
You must be new here.
Google says Results 1 - 10 of about 91,600 for "move along, nothing to see here" -site:slashdot.org.
So, uh, why don't you open source wizards recompile DTrace without the code that checks P_LNOATTACH?
Given what you're going to use the Air for, what's the problem with a slow hard disk? I mean, it's not going to affect word processing, spreadsheeting, or web surfing noticeably. Slightly longer boot times? This isn't a suitable machine for doing media creation and editing on, period. I think it's a reasonable compromise.
Also, that 5 hours is using the WiFi, which you won't be using on a plane trip.
You're fired.
If you aren't writing clear and understandable code, I don't want you on my project.
What, someone's going to break into your house in the middle of the night and install XP on your machine? Grow up.
The PPC core in the PS3 is pretty basic, executes only in-order, and can probably be outperformed by a Core 2 at 2.4GHz. You wouldn't gain anything by going PPC/Cell instead of Intel/Cell, and you'd lose Windows compatibility.
The PS3 doesn't run Linux; the development tools provided by Sony are Linux-based. This is a common misconception dating back from the PS2 days. "Cell" isn't really the PPC core anyway, and the PPC CPU in the PS3 is outperformed by any current Intel offering.
The Product Briefing you link is very vague as to what the "firmware framework" actually contains: "PortalPlayer(TM) supports the PP5022 with an embedded firmware framework and FDK that includes robust development tools enabling custom feature sets and enhancements. The FDK allows developers to rapidly create differentiated platforms based on a complete suite of standard functions, database engines, codecs, etc." I'd be very surprised if they offer any firmware with functionality at a higher level than, e.g., block DCT. Do you have any evidence to the contrary?
So would you like all manufacturers to be forced to limit their markup, or just Apple?
The third party decoder chip has WMA support in much the same way that Intel CPUs have support for Linux and OSX executables.
Microsoft deliberately designed their Windows software so that it can only run a single executable program format, their so-called Portable Executable format. Clearly the Intel CPU on a Windows PC can run Mac OSX apps and Linux apps. Can I sue Microsoft for not implementing the ability to run OSX and Linux apps?
Is there any labeling requirement for HD/BD releases to tell which codec they're using? If there's no guarantee that HD/BD is going to use a modern codec, I think I'm going to continue to buy movies off the iTunes store, since I can assume they're going to be using H.264.
I've heard stories that UFOs are real.
X-15 is a rocket, not a jet. SR-71's official mach 3.3 probably isn't dramatically less than its actual top speed.
I myself have never stabbed a designer with an icicle, and my lawyer resents the implication.
Then the lead engineer gets hit by a twinkie truck, one of the designers gets stabbed with an icicle, one programmer is out for a while because she's donating a kidney to her best friend, another programmer isn't getting any work done because he's going through a divorce, and a third is writing crap code because he isn't getting any sleep because he and his wife just had twins, and in the end it's all you can do to make the engine limp along just well enough to ship another game and make payroll and try and stay afloat long enough to try to do it better next year.
We pack multiple characters' resources together into larger load units to avoid the overhead of small reads broken up by disk seeks (console optical disks really suck at the seek). We can't load and unload a character at a time, as a general rule, and by making the common memory area dynamic, you open yourself up to fragmentation and make it impossible to predict at runtime whether you'll have enough memory to load the common resources you need after a given sequence of region-to-region moves in the game. There are a lot of smart suggestions being made in this thread. There have been a lot of smart suggestions made in the corridors and cubicles of game companies for the last ten years, too.
Actually, memory management for third party libraries is mostly a tractable problem now -- the good ones have memory allocation hooks, so you can give them small private memory arenas that won't create fragmentation in other memory spaces. But that's more engine complexity for you.