and its notoriously difficult to "undo". Scripting doesn't even get close. And people wonder why compositing software like Shake costs thousands of dollars.
This will be the beginning of the end of these issues.
If RPMForge can succeed then 3rd party developers can use their lessons-learned (build tools) to release packages or create repositories that work on as many systems as possible.
Also I hope (as mentioned by another poster) that some base RPM dependancy names are adopted for truly cross-distribution packages.
I think the best solution would be for RPMForge could create distribution-specific packages that add these symbolic entities into the RPM database.
So like on SuSE the lsb-3.1.i386.rpm would have as its dependancies packages that come with SuSE distributions whereas in the RHEL4 tree it would have a similar but slightly different dependancy list... and both would provide 'lsb 3.1' or whatever. Any required "patches" would be in that requirement list... so if SLES 9 has some issue with complying with LSB 3.1 rather than wait for Novell to patch it RPMForge could release rpmforge-lsb-sles-9-compat.i386.rpm which adds some files or runs a script to make it compliant.
Much of Windows uses the MSHTML engine. IE also uses it.
But IE does a lot more stuff. The stuff that is most problematic (aside from buffer overflow-type problems which happen all over in most OSs) is how it is tied to the Windows Scripting Host and the security model it uses to determine who can do what in which context. It also exposes an intractible number of APIs to audit.
There were a couple real bad remote exploits that hit the MSHTML engine but not nearly as many as IE overall. Most problems that people run into browsing the internet and getting drive-by-hacked have to do with IE's not-so-consistent treatment of content from untrusted sources -- and then there's the issue of the LSP framework (something that should never have been introduced) -- the LSP should have at least had a very clear exposure to user space [i.e. control panel] so that changes to it could be detected.
So it's not so much IE that's the security problem. It's all the bits and pieces that get tied together by it without enough thought or adequate protection.
I'm very sure that wasn't Linus's intention to imply. Something as audacious as suggesting COW in general is flawed when it is a critical component of the current VM would have garnered very different reactions on the LKML where people are savvy about such things.
His comments are being taken out of context. You have to read the whole emails to get a feeling for what he's trying to say. It annoys me that people also feel that Linus is critizing FreeBSD coders in general; that barb was directed at those who thought that use of the semantics was a good thing (FreeBSD contributor and/or persons suggesting Linux should use it too) Not so much ad hominem as much an unsubtantiated (but not unfounded) claim.
PTE overhead is 1K per 1M of (actively) mapped memory. This is the sum of used (not allocated) user pages, memory maps/buffer cache, and kernel buffers. Generally speaking a linux system tends to want to push the overall usage towards the physical memory limit. If a system has 2G of physical RAM, the linux system generally will end up with about 2M worth of PTEs and directories after running for awhile.
The reason why the system slows down when you trounce all over 80% of memory is because a very large portion of that memory space is dedicated to file buffers and the data segment of dormant daemons and such. By trouncing all over active memory you evict many process spaces to swap and free read-only shared memory... forcing daemons to reload libraries and such when they wake up and start page faulting. Also the kernel uses heuristics to determine when a program is misbehaving and writing to abnormally large "working sets" and it can evict you before you allocate and write to the theoretical limit you should be able to. The kernel reserves overhead of possibly usable memory for DMA destinations and other processes, swapin space, whatever.
Sounds like you needed more swap anyway, if that was the case. I've been able to exceed 100% easily... its slow, of course.:-)
The fake memory copy is still stupid... but for different reasons. It looked good on paper, but it even didn't work very well on a single CPU system. The mach case was not for the kind of implicit COW you get for forking and file sharing and stuff, but for "sending" a userspace buffer to another thread.
But yes, the COW overhead still comes into play which invalidates it all. But he also mentions that really the "copy" if it was explicit instead is in fact very light since its handled by the caches and doesn't involve a TLB flush as the sizes are small. If the sizes are large, then you're doing something fundanmentally wrong and perhaps you should be using SHM and semaphores explicitly.
Anyway his comment about Microsoft is pretty accurate. They were the first people to start pushing the idea of exposing the file buffers directly to network DMA to get speed. Windows NT is actually a good platform for this what with IO completetion ports and other nice backend stuff. But IIS would be the last platform I would want to deploy something like that on (especially in version 4/5).
But having some many layers of caches and coherency protocols makes trying to circumvent all of it dicey unless you OOB communicate your intentions. You also have to balance accounting overhead vs. slow method with no overhead -- common fast case vs. fast case "predicition misses" in all types I/O handling.
Linus is making a claim of bad balancing in fast case vs. prediction miss and overemphasizing overhead costs in the case of the COW sendfile/zero_copy semantics. Mach was making a similar mistake... hence the grandparents' comment. This parallel was insufficiently shown.
This is about streaming. fork() never entered the discussion. Everyone uses COW on fork(). That's never been an issue.
The "issues" you bring up about linux systems with slow startup times or whatever you wrote 4 paragraphs about are non-existant. And copying memory pages certainly wouldn't result in a freeze in any case. Apparently you've never used a decent Unix system so how the hell would you know anyway. Please go take a class in OS design while you're add it, then you can contribute your ill-informed non-sequitirs to the discussion.
This is about big-boy networking stuff. You go play with your toy OS.
This article had NOTHING TO DO with forking and shared memory between processes. That is very COW and will never change. And really there is very little COW that happens on forking. Generally process share inhereited mmaps to library files and programs across fork that are read only anyway. Buffer cache is buffer cache and forking just copies pointers. Pages which are mmap shared get the COW semantics and thats a known quantity.
This is entirely about streaming and zero copy networking (where user-space gives buffers to the kernel or vice versa). This is a tricky area and the semantics are difficult.
Its not COW in general that he has a problem with. COW when using rarely modified pages in userspace is fine. Linux relies on this for lightweight kernel threading behavior (cheap forks)... and a bunch of other stuff.
The issue at question here is transient userspace buffers for use in streaming type operations. The FreeBSD approach is to use COW semantics from userspace so that the fast case (when userspace doesn't attempt to write its own buffer) is fast, but if it does, it magically gets mapped to a new PTE with its own copy.
Linus thinks (and he's probably right) that if the user space code intended to touch a buffer that may be in flight, it might as well just do the copy anyway and use write() instead of playing with the VM so that the kernel can do things behind the userspace's back. He thinks that the extra TLB flush delay on top of the actual copy amortized over the expected rate of occurences is greater than the just always-do-it time. And that's probably a good guess considering that if the code is "streamlined" to modify a buffer right after "submission" that it was going to have to wait for a copy to be made at some point... or to wait for DMA to finish. Plus TLB flush gets VERY EXPENSIVE when you go SMP. And with all the multi-core/hyperthreading/NUMA stuff we're seeing up the wazoo out there, that's a very valid point.
So in summary... Linus wants: write() always copies... splice() lets the kernel see your page (don't touch it if you don't want to change it at the "wrong time"). Which is different than COW page buffer/mmaps/anonymous memory semantics. Different purpose completely.
The only advantage that the X-fi system gives you is the ability to mix in surround and do environemntal processing and filtering in hardware.
Starting and stopping sounds, music and straight matrix mixing them is computationally simple and does not require anything resembling "pipelines" or multiple chips or any of that bullshit. It requires a decent DMA implementation and relatively low-end MAC-capable DSP to get uber-channels. What the envy24 and crystal-sound lines have going for them especially are superior ADC/DAC paths and the support for more analog input and output channels.
Really the games can mix down the sounds in realtime easy. Its just that most games don't do jack shit in terms of preloading the environmental effects into memory, so that the first time they're used, you get a disk-hit... or god forbid they use some kind of basic synthesis. The sound engine design is always an afterthought, and it shows.
But yeah, turn off EAX. Its retarded. And if you must have accelerated surround sound with wall reflections and crap, try a Terratec DMX (envy24 + EAX acceleration DSP) or maybe a Hercules GameSurround III (cs46xx + vortex engine)
All good sound DSPs (arguably better than anything from Creative quality-wise), and they all support 8+ hardware mixed sound streams. As a bonus the envy24 has very flexible hardware mixing and routing too... so you could actually have 4 different OSs running with 4 different stereo output pairs on the same card (check the Midiman 1010 for an example of the requisite hardware incantation for 8 mono outputs).
Well, again you could use stand-in identifiers. You could leave some of them as is. Because I suspect the hardest part of dictated coding is reciting things like LD_LIBRARY_PATH over and over. Its critical that for the duration of your dictation can use some other term, or a number (if you just need a temporary local that'd be easier)
So instead you might have:
new function shrink set local hello ref in 1 if test empty ref local hello end test...
do you want to rename function "shrink": hello_lower do you want to rename local variable "hello": (carriage return)
or perhaps:
new function ident hello lower end ident which would optionally prompt: what do you want to call function "hello lower": hello_lower
or for an extreme example:
set explicit upper l d under word library under word path end explicit slash o p t slash c s w slash l i b colon ref explicit upper l d under word library under word path end explicit (for LD_LIBRARY_PATH="/opt/csw/lib":$LD_LIBRARY_PATH ... yeeesh) contrast: set ID library path end ID string ID blast wave lib end ID colon ref ID library path end ID and cue appropriate prompts The thing is you have to be able to read what the dictation software outputs into your text editor and be able to work with it... so its probably better to have standins than try to tell educate the voice->text program about your commonly used identifiers (although it would be nice to preload it with some common idioms)
First, find a solution that makes it easy to enter text into a GUI (gnome accessibility, WINE w/dragon natural speaking, whatever).
Find a subset of words that are short, easy to remember, easy to say, and above all -- accurately translated by the chosen voice recognition software.
Then create a small perl script that can take this coded input and convert it into a nicely formatted chunk of code.
You can have different translators for different target languages... for example
In shell programming, you might have the following:
hash -> # bang -> ! pipe -> | test -> [ end test -> ] mark -> ' quote -> " end mark/quote (keeps them balanced for shell scripts)
for identifiers... don't name them. For example, lets' say you wanted to do this: #!/bin/bash function hello_lcase {
HELLO = $1
if [ -z $HELLO ] ; then
echo "Hello world"
else
echo -n "Hello from "
echo $HELLO | sed -e 's/.*/\L\0/'
fi }
you would say:
hash bang slash bin slash bash new function 1 set local 1 ref in 1 if test empty ref local 1 end test then echo string 1 else echo option n string 2 echo ref local 1 pipe program s e d option e space mark s slash dot star slash back upper l back 0 slash end mark end if end function 1
you'd run the perl script and it'd ask you:
what do you want to call function 1: foo what do you want to call local variable 1 in function 1: HELLO what do you want to use for string resource 1: Hello World what do you want to use for string resource 2: Hello from
and it'd output the script (maybe after running through indent)
You could substitute "1" for any easily recalled mnemonic or symbol the text->speech translator is unlikely to mistranslate (in this case "foo" and "hello" would probably be fine as is) Then you'd get a chance to globally "refactor" your symbols and give them nice-looking names, only having to type them once.
... what makes Lenovo different than IBM being in charge is the IBM name, and IBM's ability to market to its customer base.
That's the struggle that an ODM is going to face in the American market... figuring out the posturing and branding, and building a reputation. Taiwan has a tendancy to try to direct-sell stuff just because they can -- relying on the OEMs or distributors to pick what will sell out from the stuff that misses the mark. That kinda stuff might work at WalMart but it won't work in corporate America (at least not in the same ways). It will be difficult for them to reach the Western consumers directly unless they already know how to cater to corporate needs. And the value of brand inertia can't be underestimated... I'm surprised the chucked the IBM logo so quickly. I hope its because they hope to gain converts and let the product stand on its merits.
What tends to happen is that companies like Motorola, Intel, NVidia and Broadcomm first release their development/platform kits. These are the recommended designs that form the basis of entire line of end-user products. Companies like Quanta, Asus, Foxconn start experimenting with the platform and find ways to productize them. Then they pitch designs to OEMs like Dell, HP and Apple, which turn around and offer counter-suggestions and improvements, branding/tiering choices, etc. Sometimes though the OEM buys into the design with hardly any changes at all, this is the ODM case. But even the "OEM" cases aren't really much engineering at all. The a large part of OEM is the branding (and sometimes software/firmware).
Most of the components are Intel-sourced, which are made in malaysia and designed by international teams. The Powerbooks are manufactured by Quanta out of Taiwan.
The design is Apple, but the components come from everywhere.
This becomes a moot issue when you can obtain a 24-port gigabit switch with an internal 48 gbps fabric for less than $200. CSMA vs. token passing is irrelevant since all packets are handled and queued on dedicated links. If every port isn't directly switched on your network, then someone fucked up. There's just no excuse.
I have found that I particularly like certain varities of flourescent bulb over any other type of light source. I like those in the range of 5800-6300K best. There is a certain comfort when the light has a certain characteristic spectrum (and not one mimicing daylight, but more like "overcast sky").
And if you read the article, you'd know that this point is encapsulated in the pro-gamers representation of the current status quo, as I mentioned earlier.
It shouldn't matter. If a chick in a coed team creams a top seat in a tournament, you don't think she'd get coverage even if she wasn't a looker?
If the tourneys were co-ed, then image wouldn't need to be a pre-requisite for sponorship, just skills. I mean, isn't this the internet? Where no one knows your a dog until they meet you in person?
The only time you here the buzzwords is when talking about things from our clients' perspective -- and when they're written on powerpoint slides, it's always in "quotes".
The main point at issue was whether or not the status quo in the professional circuit (and in the media) is inadequate to uncover the truly talented female gamers.
The pro-gaming insider thinks so. The mag-editor OTH thinks its a matter of the right groups of females teaming up in the first place.
I tend to agree with the latter. The status quo will only change when a female team (or GASP, a coed team) emerges that competes well enough such that it would be illogical to cover the female members on their own merits.
The "Windows Tax" on the cost of a laptop is the cost of an upgraded keyboard. All of the Dell laptops I've tried work just fine with just about any linux distro, and the latitudes (can't speak for the inspirons) especially well w.r.t. hibernation and other power management stuff. Dell won't ship hardware that's hard to support in linux, believe it or not. One exception is centrino wifi, but that's an Intel issue (which is basically resolved now)
Slashdot Mirror
and its notoriously difficult to "undo". Scripting doesn't even get close.
And people wonder why compositing software like Shake costs thousands of dollars.
http://rpmforge.net/manifest.php
This will be the beginning of the end of these issues.
If RPMForge can succeed then 3rd party developers can use their lessons-learned (build tools) to release packages or create repositories that work on as many systems as possible.
Also I hope (as mentioned by another poster) that some base RPM dependancy names are adopted for truly cross-distribution packages.
I think the best solution would be for RPMForge could create distribution-specific packages that add these symbolic entities into the RPM database.
So like on SuSE the lsb-3.1.i386.rpm would have as its dependancies packages that come with SuSE distributions whereas in the RHEL4 tree it would have a similar but slightly different dependancy list... and both would provide 'lsb 3.1' or whatever. Any required "patches" would be in that requirement list... so if SLES 9 has some issue with complying with LSB 3.1 rather than wait for Novell to patch it RPMForge could release rpmforge-lsb-sles-9-compat.i386.rpm which adds some files or runs a script to make it compliant.
Tie this together with yum...
Much of Windows uses the MSHTML engine.
IE also uses it.
But IE does a lot more stuff. The stuff that is most problematic (aside from buffer overflow-type problems which happen all over in most OSs) is how it is tied to the Windows Scripting Host and the security model it uses to determine who can do what in which context. It also exposes an intractible number of APIs to audit.
There were a couple real bad remote exploits that hit the MSHTML engine but not nearly as many as IE overall.
Most problems that people run into browsing the internet and getting drive-by-hacked have to do with IE's not-so-consistent treatment of content from untrusted sources -- and then there's the issue of the LSP framework (something that should never have been introduced) -- the LSP should have at least had a very clear exposure to user space [i.e. control panel] so that changes to it could be detected.
So it's not so much IE that's the security problem. It's all the bits and pieces that get tied together by it without enough thought or adequate protection.
God I'm wet.
I'm very sure that wasn't Linus's intention to imply. Something as audacious as suggesting COW in general is flawed when it is a critical component of the current VM would have garnered very different reactions on the LKML where people are savvy about such things.
His comments are being taken out of context. You have to read the whole emails to get a feeling for what he's trying to say. It annoys me that people also feel that Linus is critizing FreeBSD coders in general; that barb was directed at those who thought that use of the semantics was a good thing (FreeBSD contributor and/or persons suggesting Linux should use it too) Not so much ad hominem as much an unsubtantiated (but not unfounded) claim.
PTE overhead is 1K per 1M of (actively) mapped memory. This is the sum of used (not allocated) user pages, memory maps/buffer cache, and kernel buffers.
:-)
Generally speaking a linux system tends to want to push the overall usage towards the physical memory limit. If a system has 2G of physical RAM, the linux system generally will end up with about 2M worth of PTEs and directories after running for awhile.
The reason why the system slows down when you trounce all over 80% of memory is because a very large portion of that memory space is dedicated to file buffers and the data segment of dormant daemons and such. By trouncing all over active memory you evict many process spaces to swap and free read-only shared memory... forcing daemons to reload libraries and such when they wake up and start page faulting. Also the kernel uses heuristics to determine when a program is misbehaving and writing to abnormally large "working sets" and it can evict you before you allocate and write to the theoretical limit you should be able to. The kernel reserves overhead of possibly usable memory for DMA destinations and other processes, swapin space, whatever.
Sounds like you needed more swap anyway, if that was the case. I've been able to exceed 100% easily... its slow, of course.
The fake memory copy is still stupid... but for different reasons. It looked good on paper, but it even didn't work very well on a single CPU system. The mach case was not for the kind of implicit COW you get for forking and file sharing and stuff, but for "sending" a userspace buffer to another thread.
But yes, the COW overhead still comes into play which invalidates it all. But he also mentions that really the "copy" if it was explicit instead is in fact very light since its handled by the caches and doesn't involve a TLB flush as the sizes are small. If the sizes are large, then you're doing something fundanmentally wrong and perhaps you should be using SHM and semaphores explicitly.
Anyway his comment about Microsoft is pretty accurate. They were the first people to start pushing the idea of exposing the file buffers directly to network DMA to get speed. Windows NT is actually a good platform for this what with IO completetion ports and other nice backend stuff. But IIS would be the last platform I would want to deploy something like that on (especially in version 4/5).
But having some many layers of caches and coherency protocols makes trying to circumvent all of it dicey unless you OOB communicate your intentions. You also have to balance accounting overhead vs. slow method with no overhead -- common fast case vs. fast case "predicition misses" in all types I/O handling.
Linus is making a claim of bad balancing in fast case vs. prediction miss and overemphasizing overhead costs in the case of the COW sendfile/zero_copy semantics.
Mach was making a similar mistake... hence the grandparents' comment. This parallel was insufficiently shown.
This is about streaming.
fork() never entered the discussion.
Everyone uses COW on fork(). That's never been an issue.
The "issues" you bring up about linux systems with slow startup times or whatever you wrote 4 paragraphs about are non-existant. And copying memory pages certainly wouldn't result in a freeze in any case. Apparently you've never used a decent Unix system so how the hell would you know anyway. Please go take a class in OS design while you're add it, then you can contribute your ill-informed non-sequitirs to the discussion.
This is about big-boy networking stuff. You go play with your toy OS.
This article had NOTHING TO DO with forking and shared memory between processes. That is very COW and will never change.
And really there is very little COW that happens on forking. Generally process share inhereited mmaps to library files and programs across fork that are read only anyway. Buffer cache is buffer cache and forking just copies pointers. Pages which are mmap shared get the COW semantics and thats a known quantity.
This is entirely about streaming and zero copy networking (where user-space gives buffers to the kernel or vice versa). This is a tricky area and the semantics are difficult.
Thank you. Finally someone gets the big picture and the whole argument here.
Its not COW in general that he has a problem with. COW when using rarely modified pages in userspace is fine. Linux relies on this for lightweight kernel threading behavior (cheap forks)... and a bunch of other stuff.
The issue at question here is transient userspace buffers for use in streaming type operations. The FreeBSD approach is to use COW semantics from userspace so that the fast case (when userspace doesn't attempt to write its own buffer) is fast, but if it does, it magically gets mapped to a new PTE with its own copy.
Linus thinks (and he's probably right) that if the user space code intended to touch a buffer that may be in flight, it might as well just do the copy anyway and use write() instead of playing with the VM so that the kernel can do things behind the userspace's back. He thinks that the extra TLB flush delay on top of the actual copy amortized over the expected rate of occurences is greater than the just always-do-it time.
And that's probably a good guess considering that if the code is "streamlined" to modify a buffer right after "submission" that it was going to have to wait for a copy to be made at some point... or to wait for DMA to finish.
Plus TLB flush gets VERY EXPENSIVE when you go SMP. And with all the multi-core/hyperthreading/NUMA stuff we're seeing up the wazoo out there, that's a very valid point.
So in summary... Linus wants: write() always copies... splice() lets the kernel see your page (don't touch it if you don't want to change it at the "wrong time").
Which is different than COW page buffer/mmaps/anonymous memory semantics. Different purpose completely.
The only advantage that the X-fi system gives you is the ability to mix in surround and do environemntal processing and filtering in hardware.
Starting and stopping sounds, music and straight matrix mixing them is computationally simple and does not require anything resembling "pipelines" or multiple chips or any of that bullshit. It requires a decent DMA implementation and relatively low-end MAC-capable DSP to get uber-channels. What the envy24 and crystal-sound lines have going for them especially are superior ADC/DAC paths and the support for more analog input and output channels.
Really the games can mix down the sounds in realtime easy. Its just that most games don't do jack shit in terms of preloading the environmental effects into memory, so that the first time they're used, you get a disk-hit... or god forbid they use some kind of basic synthesis. The sound engine design is always an afterthought, and it shows.
But yeah, turn off EAX. Its retarded.
And if you must have accelerated surround sound with wall reflections and crap, try a Terratec DMX (envy24 + EAX acceleration DSP) or maybe a Hercules GameSurround III (cs46xx + vortex engine)
All good sound DSPs (arguably better than anything from Creative quality-wise), and they all support 8+ hardware mixed sound streams.
As a bonus the envy24 has very flexible hardware mixing and routing too... so you could actually have 4 different OSs running with 4 different stereo output pairs on the same card (check the Midiman 1010 for an example of the requisite hardware incantation for 8 mono outputs).
Well, again you could use stand-in identifiers. You could leave some of them as is. Because I suspect the hardest part of dictated coding is reciting things like LD_LIBRARY_PATH over and over. Its critical that for the duration of your dictation can use some other term, or a number (if you just need a temporary local that'd be easier)
...
... yeeesh)
So instead you might have:
new function shrink
set local hello ref in 1
if test empty ref local hello end test
do you want to rename function "shrink": hello_lower
do you want to rename local variable "hello": (carriage return)
or perhaps:
new function ident hello lower end ident
which would optionally prompt:
what do you want to call function "hello lower": hello_lower
or for an extreme example:
set explicit upper l d under word library under word path end explicit slash o p t slash c s w slash l i b colon ref explicit upper l d under word library under word path end explicit
(for LD_LIBRARY_PATH="/opt/csw/lib":$LD_LIBRARY_PATH
contrast:
set ID library path end ID string ID blast wave lib end ID colon ref ID library path end ID
and cue appropriate prompts
The thing is you have to be able to read what the dictation software outputs into your text editor and be able to work with it... so its probably better to have standins than try to tell educate the voice->text program about your commonly used identifiers (although it would be nice to preload it with some common idioms)
First, find a solution that makes it easy to enter text into a GUI (gnome accessibility, WINE w/dragon natural speaking, whatever).
Find a subset of words that are short, easy to remember, easy to say, and above all -- accurately translated by the chosen voice recognition software.
Then create a small perl script that can take this coded input and convert it into a nicely formatted chunk of code.
You can have different translators for different target languages... for example
In shell programming, you might have the following:
hash -> #
bang -> !
pipe -> |
test -> [
end test -> ]
mark -> '
quote -> "
end mark/quote (keeps them balanced for shell scripts)
for identifiers... don't name them. For example, lets' say you wanted to do this:
#!/bin/bash
function hello_lcase {
HELLO = $1
if [ -z $HELLO ] ; then
echo "Hello world"
else
echo -n "Hello from "
echo $HELLO | sed -e 's/.*/\L\0/'
fi
}
you would say:
hash bang slash bin slash bash
new function 1
set local 1 ref in 1
if test empty ref local 1 end test
then
echo string 1
else
echo option n string 2
echo ref local 1 pipe program s e d option e space
mark s slash dot star slash back upper l back 0 slash end mark
end if
end function 1
you'd run the perl script and it'd ask you:
what do you want to call function 1: foo
what do you want to call local variable 1 in function 1: HELLO
what do you want to use for string resource 1: Hello World
what do you want to use for string resource 2: Hello from
and it'd output the script (maybe after running through indent)
You could substitute "1" for any easily recalled mnemonic or symbol the text->speech translator is unlikely to mistranslate (in this case "foo" and "hello" would probably be fine as is)
Then you'd get a chance to globally "refactor" your symbols and give them nice-looking names, only having to type them once.
... what makes Lenovo different than IBM being in charge is the IBM name, and IBM's ability to market to its customer base.
That's the struggle that an ODM is going to face in the American market... figuring out the posturing and branding, and building a reputation. Taiwan has a tendancy to try to direct-sell stuff just because they can -- relying on the OEMs or distributors to pick what will sell out from the stuff that misses the mark. That kinda stuff might work at WalMart but it won't work in corporate America (at least not in the same ways). It will be difficult for them to reach the Western consumers directly unless they already know how to cater to corporate needs. And the value of brand inertia can't be underestimated... I'm surprised the chucked the IBM logo so quickly. I hope its because they hope to gain converts and let the product stand on its merits.
What tends to happen is that companies like Motorola, Intel, NVidia and Broadcomm first release their development/platform kits.
These are the recommended designs that form the basis of entire line of end-user products.
Companies like Quanta, Asus, Foxconn start experimenting with the platform and find ways to productize them.
Then they pitch designs to OEMs like Dell, HP and Apple, which turn around and offer counter-suggestions and improvements, branding/tiering choices, etc.
Sometimes though the OEM buys into the design with hardly any changes at all, this is the ODM case. But even the "OEM" cases aren't really much engineering at all. The a large part of OEM is the branding (and sometimes software/firmware).
Most of the components are Intel-sourced, which are made in malaysia and designed by international teams.
The Powerbooks are manufactured by Quanta out of Taiwan.
The design is Apple, but the components come from everywhere.
This becomes a moot issue when you can obtain a 24-port gigabit switch with an internal 48 gbps fabric for less than $200. CSMA vs. token passing is irrelevant since all packets are handled and queued on dedicated links.
If every port isn't directly switched on your network, then someone fucked up. There's just no excuse.
I have found that I particularly like certain varities of flourescent bulb over any other type of light source. I like those in the range of 5800-6300K best. There is a certain comfort when the light has a certain characteristic spectrum (and not one mimicing daylight, but more like "overcast sky").
And if you read the article, you'd know that this point is encapsulated in the pro-gamers representation of the current status quo, as I mentioned earlier.
It shouldn't matter. If a chick in a coed team creams a top seat in a tournament, you don't think she'd get coverage even if she wasn't a looker?
If the tourneys were co-ed, then image wouldn't need to be a pre-requisite for sponorship, just skills.
I mean, isn't this the internet? Where no one knows your a dog until they meet you in person?
The only time you here the buzzwords is when talking about things from our clients' perspective -- and when they're written on powerpoint slides, it's always in "quotes".
254 billion in sales, US GDP is 11.7 trillion, so 2.2% GDP
The main point at issue was whether or not the status quo in the professional circuit (and in the media) is inadequate to uncover the truly talented female gamers.
The pro-gaming insider thinks so. The mag-editor OTH thinks its a matter of the right groups of females teaming up in the first place.
I tend to agree with the latter. The status quo will only change when a female team (or GASP, a coed team) emerges that competes well enough such that it would be illogical to cover the female members on their own merits.
The "Windows Tax" on the cost of a laptop is the cost of an upgraded keyboard.
All of the Dell laptops I've tried work just fine with just about any linux distro, and the latitudes (can't speak for the inspirons) especially well w.r.t. hibernation and other power management stuff.
Dell won't ship hardware that's hard to support in linux, believe it or not. One exception is centrino wifi, but that's an Intel issue (which is basically resolved now)