This seems ridiculously high to me. 5% of computers are unusable in the first month? No explanation is give of what constitutes "unusable". Does it mean the hard drive is physically crapped out or something like "the Internet is broken again"?
When we bought a bunch of PCs to build a cluster here in the lab, one out of 16 did not work (I think it was the motherboard, I can't remember), while 16 is not exactly a good sampling, the failure rate was above 5%. Between hardware duds, shippement errors, installation errors and configuration problems, 5% seems quite resonable to me. While the average/. guy could probably solve those problems, the average user cannot.
Also note, that "the internet is not working" is a good definition of unusable if you bought the computer to go on the internet. When rating customer satisfaction having an objective reference makes little sense.
Furthermore, Apple is a terrible company to include in this kind of survey. A very large percentage of their customers
are Mac enthusiasts. Not that there's anything wrong with that, it's just that comparing an Apple customer's perception
of Apple support with a Dell customer's perception of Dell support is hardly an accurate picture - the Dell customer has
no particular love for the company.
Huh? Because Apple customers like Apple products they should be excluded of a customer satisfaction survey?
You argue that because they are Mac enthousiast they will have a better perception of Apple's tech support. Has it occured to you that maybe Mac enthousiast are enthousiastic because of the quality of Apple's tech support and that the probable reason that the Dell customer has no particular love for the company is because their products are not very satisfying...
The gcc compiler is shipped by default on Mac OS X and is also the compiler of Apple's IDE: project builder. Darwin is usually compiled with gcc. So I suppose that you could say that gcc is the default compiler of OS X.
I don't know what part of the OS X binary are actually compiled with gcc, probably a large majority. It seems that the Finder (OS X's graphical shell) is built using the powerplant framework, and therefore probably compiled using metrowerk's compiler.
I also heard some rumors that parts of the kernel where compiled using metrowerk's compiler because it does a better job of optimising PPC code, then again this is a rumor.
Mac OS simply will not run without the hardware ROMs.
This is getting less and less true, so called new world machines only rely on the ROM for booting (all machines since the iMac are new worlds machines). The ROM that contains the toolbox code is basically a memory mapped file (you can see this file in the system folder).
Darwin does not need any special ROMs (how would it run on x86 machines?). And Mac OS X basically runs on top of darwin (this is how unsupported machines can run OS X). The only part of the Mac ROM that needs to be somehow emulated is the open firmware booting code that sets up the device tree and hands it to the kernel. Open firmware is IEEE standard.
So roughtly to run OSX on a unsupported machine, you need to implement a booting system that can hand a device tree to the kernel and write darwin drivers for your hardware / emulation plateform. As far as I know, you can do both legally.
Of course there might be some hidden checks in OSX, but the open source nature of Darwin make this improbable. I don't think that Apple will care about this simply because it does not seem to be a serious threat to their marketshare...
Indeed many cities are built on the border of rivers, but those rivers exist before they flow into the city and after they run out of it.
So if the change of temperature was only caused by the body of water, the whole river would cause rain down-wind (this is probably true, but is an orthogonal problem).
Claiming that the observed effects can be explained by the rivers would imply that those river do not exist outside of the city...
The next version of Sherlock should be much more like Watson, i.e offer an Aqua interface to many web services. For this, a javascript engin will come in handy.
I think this is good news, it shows that the KDE code is good, and that Apple is willing to contribute back.
The interesting thing for me is that it shows a good trend, i.e that OS X is converging with other Unixes not only at low level (Jaguar should sync with a more recent version of BSD) but also at the component/framework level: beside this Javascript component, CUPS is scheduled to be included in Jaguar.
An interesting question would be, what other open source components/framework would be good additions to Mac OS X? I suppose one obvious answer is a native version of GTK
As far as I understand, UFS support in OS X is mostly legacy: previous versions (Mac OS X server 1.0 for instance) relied more heavily on it. In Mac OS X, HFS+ has been optimised more heavily than UFS.
Also understand that many carbon applications have trouble coping with non-HFS+ file-systems. Here in the lab, I mount my solaris home directory thru NFS, and some carbon apps cannot start from my home directory because of this. Some carbon applications even have trouble with files in this file-system (on bad days Acrobat Reader tells me the file does not exist).
As applications and system frameworks become more file-system agnostic. I suspect Apple will probably put less emphasis on HFS+ and put more effort in other file-systems.
QuickTime was ported to Windows very early, maybe version 1, but I'm quite sure about version 2. This was in the early 90's and Linux was not important at that time.
QuickTime is media compression framework. IMHO it does not rely a lot on the Macintosh Toolbox, its more the reverse: the Macintosh Toolbox (QuickDraw most notably) relies on the QuickTime framework.
Apple never ported QuickTime to Linux because they never had a reason to. Basically Apple gets money when either somebody uses or licenses QuickTime for their application or when somebody buys a Mac.
This does not mean that porting QuickTime for Linux would be difficult. They basically ported it to BSD (Darwin) - the only significant difference would be the frame-buffer interface.
In my experience, finding an IT job in switzerland is still relatively easy. People I know that moved to the US during the internet craze are coming back here, and managed to find jobs.
I agree that the main problem might well be the culture schock. In my experience, people from the US tend to underestimate this factor and have trouble adjusting to the way things work around here. Things are usually not better or worse than in the US, but simply different: paperwork, the way things are done, relationships between people, social customs, etc.
Also don't underestimate the paperwork - switzerland is a nation of bank and insurance companies. There is a lot of paperwork especially if you are a foreigner. And if you only speak english, it will be even slower.
Whenever you end up in the german speaking part or the french speaking part, you'll need to learn a local language. Many people, especially in cities like Zurich or Geneva know some english and many things are labelled in english nowadays. Still learning a local language helps for day to day life and socialising.
You can, to some extent, avoid this, especially in Geneva, where there is a large english speaking community. Some of those guys stayed for more than twenty years in Geneva and still don't know a word of french. Somehow I thing that by doing this, you miss something...
The problem with volcanoes, as far as I understand, is that the ashes are propelled quite high in the atmosphere, and thus can spread far and wide, sometimes thousands of kilometers away. Debris from the WTC probably did not go further than a few blocks. I don't think it makes sense to put the explosion of a building, even a large one, in the same category than a large volcano.
Also, large buildings are blown up all the time when they are demolished - albeit usually there are no people inside. But from the meteorological point of view, it proably makes little difference.
The port/implementation that is proposed is not of Cocoa, but of Carbon. Cocoa is the API that is inherited from Next, Carbon is the API inherited from the Macintosh Toolbox.
This implementation would not permit such things as Cocoa (or Carbon) versions of GNUCash. Instead this would mean that current carbon applications (Microsoft Office, Photoshop) could be compiled to run on a Linux like system.
Doing this would mainly require a lot of work., Carbon is quite a large API. Among the issues I see:
GUI API - this might be tricky because the structural relationships between the elements are different. There is only one common menu, and there is no relationship (parent - child) between windows.
QuickDraw. This is the imaging model used by Carbon. While it is not as advanced as Quartz, it is still quite complex. One good idea would be to implement QuickDraw on top of OpenGL.
I/O - the File Manager and the Resource Manager will need to be remplemented. This can be tricky on a Unix file system (no forks, different path separators). There was a good paper on the issues related to this.
The reason you will probably be unable to run carbon binaries is simply because those binaries are targeted for a PPC processor, not an 8086 processor.
As for source compatbility, the design differences between linux and classic Mac systems is rougtly the same than the difference between Mac OS 9 and Mac OS X.
Carbon was designed to be implemented on a Unix core. If the Carbon layer is correctly implemented then it should work.
Actually, there are many advantages for compiling your latex code directly to pdf. In fact, this is what I'm doing on my solaris box.
I used to compile to dvi and then convert to Postscript because most of the figures I used were eps files. Most people in the lab are still working this way. When there are eps figures, xdvi basically call ghostview to convert the eps to a bitmap.
The advantages of compiling to pdf are numerous:
Compactness - pdf files are very compact.
Good viewer - previewing your files using acroread means you get good anti-aliasing, which is less tiring.
Portable, pdf files can be viewed on many plateforms (more that dvi or Postscript at any rate). Also most conferences and journals accept pdf files.
Better spacing algorithm - pdftex uses a special justification algorithm that tweaks the shape of characters - this avoids some "box overfull" messages.
The hyper-ref package - all internal references are hyper-links, and the pdf outline is built from the latex structure. Very cool.
With a little bit of fiddling I built a.bbl file that insert hyper-links to the original paper in the bibliography if there is an "url" entry in the.bib file.
This is typical, many Apple docs were peppered with jokes. The examples for the GUI in the Inside Macintosh were about about SurfWriter, the coolest word processor (or something like that). Most glossaries had an (incomplete) entry for RTFM, etc...
A long time ago, our school (the Swiss Federal Institute of Technology in Lausanne) built its own computer, it was called smacky...
Writing Game yes, but for art
on
WineX 2.0
·
· Score: 2
I think you are missing half of the part of games: game ideas and art. You are right, there are a lot of geek-work for building game libraries and clones of games. The problem is, the art part is not following. Take a look a freecraft the code is quite advanced, but basically the game relies on the artwork of Warcraft. The "original" art designed by OS comunity is quite awfull.
Until the OS community is joined by skilled art people OS games will be limited.
Soldier talking to the media tend to be very positive about stuff comming from their side - or be in trouble.
Most food I ate in the military was officially considerd delicious (edible if you are hungry) or very good (tastes like dog food). If they told the press that the food is acceptable, I cannot fathom how disgusting this must be... shudder.
As far as I know, photoshop is very good at handling huge images, altough I don't know if it could handle such a monster. Also photoshop does CMYK. One of the main problems when handling very large images is that the default VM policy of the OS is not adapted to handle the graphic data.
Photoshop does its own VM to handle the memory needed for the image. As far as I remember it needs four times as much disk space than the original picture (this is needed for things like filtering and undo).
I don't know of a cheaper alternative that would do the trick. If I had to write such an app, I would look into mechanisms to install a custom pager that would handle the image data - using the image file as backing store - this is basically what you describe (loading the parts that are needed), but integrated with the VM mechanism.
If the app needs some basic functionality like zooming, things are a little more tricky: lets say you want to dispay a 1/10 zoomed out version of the image, then you need to process the whole file to calculate the reduced image. As this is expensive, you would probably want to cache the result.
This could again be done using a custom pager, that simply clear the memory when the pages are swapped out, and regenerate the needed pages when the memory needs to be swapped in again.
You means that this thing would contain a sensor that goes off if the kid is seriously hurt, but that does not go off when the kid is playing? Have you ever looked at a kid playing?
Measuring the pulse rate is difficult, most cheapo wristwatches that do this are very unprecise and they are designed for oldies doing their jogging, not kids that play.
I suspect the pulse rate of kid can skyrocket when it gets excited, also kids often gets a lot of minor wounds (a hard and bulky bracelet might in fact be a cause of injury) so the risk for false positives is very high. On the other hand, a kid can drown without any trace of blood.
Honnestly if you think that kids can be handled like cars, you never had to manage kids, and IMHO, you don't deserve to. The device you describe could signal that the wearer is dead. This might be very usefull for the military, but I would not consider it for parental help...
I'm no psychologue, but I suspect that if the child knows you can know were it is all the time this will have some effect. One thing childs need to do is cut the umbilical cord and become autonomous human. This kind of device might have the reverse effect. Have a problem? push the button.
Also I fear that it will create a false sense of security for parents. This gizmo might work against people would kidnap kids (which is a rare event) but won't protect them from harm (which is much more probable).
The bottom line is were is the line between protection and overprotection. If I were worried about the safety of my child, I would first consider moving to a safer place, and not letting it alone.
The problem is always the same, some people should have certain privilges, medical personel and emergency people come to the mind. The issue, is this should be a privilege (like driving a car with blue lights).
I have no problem with a medic getting a phone-call in a cinema. The problem is, I can bet that 99% of the guys using portables loudly in public places do not fall into this category. On the other hand, I don't know if people who really can be called for an emergency actually rely on off-the shelf, civilian portable phones, when they are in public places, or is this a myth (I have no idea, just wondering).
The core issue, is of course, a social problem: keeping you phone on in a public place is impolite. Solving the problem in the social context basically fails because social pressure is low and important people can break such social rules.
Of course everybody is important. Medical people must be reachable, and firemen, and policemen, and the technician monitoring critical systems (most systems are critical in one way or another), and any mother or father with young children and the CEO of any company which might go enron, and his secretary, and their psychiatrist.
Heck if anybody is unimportant enough so that he does not to need to be reachable at any time, he probably cannot afford to got to the cinema...
Trying to solve a social problem with a technical solution generally fails. If such a bluetooth solution would be implemented, everybody would bypass it. The guy you think is a jerk thinks he is important.
A social and low-tech solution would be to use the jammer and require people that need to be reachable to give their gismo at the entrance. There, the device is monitored by some guy. If a signal arrives, the guy searches the person. This would solve the technical problem (getting the information) and the social problem (medics will not objet to this, jerks will).
I don't know of any software that does the trick - but I don't think it would be that difficult to implement.
One solution to this problem would be to filter postscript files by searching if they contain any color command (like setrgb, sethsb, colorimage).
This solution is fast, but not very efficient: many postscript job contain headers that call the color operators, even if they are not needed (often they included by code that overloads such calls with a grayscale equivalent). Still this would be a first (fast) mean of finding black and white postscript filter.
A more complex, and more effective solution would be something like this.
Convert each page of the job to a low resolution bitmap (this can be done using gs and postscript management scripts)
For each bitmap page, check for colors (grascale pixel are R==G==B).
The problem of this approach is that it is quite expensive in terms of performance.
Finnally, one trick that could work would be to add some functions in the postscript header. Basically, overload all color operators so that if they are called, they flag the current page (or better they check if the color or image they are passed is really color).
If the flag is present ignore the next showpage operator and flush the graphic state.
This way you can send the job to the black and white printer, and only the color pages will show. You send a slightly different version to the color printer, but in this case, you only print the flagged pages. Voilà
That said, make sure that the black and white and the color printer are somehow similar (same resolution) if not, the two sets of pages (color and black and white), will look to different.
Slashdot Mirror
Huh? Because Apple customers like Apple products they should be excluded of a customer satisfaction survey?
You argue that because they are Mac enthousiast they will have a better perception of Apple's tech support. Has it occured to you that maybe Mac enthousiast are enthousiastic because of the quality of Apple's tech support and that the probable reason that the Dell customer has no particular love for the company is because their products are not very satisfying...
I don't know what part of the OS X binary are actually compiled with gcc, probably a large majority. It seems that the Finder (OS X's graphical shell) is built using the powerplant framework, and therefore probably compiled using metrowerk's compiler.
I also heard some rumors that parts of the kernel where compiled using metrowerk's compiler because it does a better job of optimising PPC code, then again this is a rumor.
This is getting less and less true, so called new world machines only rely on the ROM for booting (all machines since the iMac are new worlds machines). The ROM that contains the toolbox code is basically a memory mapped file (you can see this file in the system folder).
Darwin does not need any special ROMs (how would it run on x86 machines?). And Mac OS X basically runs on top of darwin (this is how unsupported machines can run OS X). The only part of the Mac ROM that needs to be somehow emulated is the open firmware booting code that sets up the device tree and hands it to the kernel. Open firmware is IEEE standard.
So roughtly to run OSX on a unsupported machine, you need to implement a booting system that can hand a device tree to the kernel and write darwin drivers for your hardware / emulation plateform. As far as I know, you can do both legally.
Of course there might be some hidden checks in OSX, but the open source nature of Darwin make this improbable. I don't think that Apple will care about this simply because it does not seem to be a serious threat to their marketshare...
So if the change of temperature was only caused by the body of water, the whole river would cause rain down-wind (this is probably true, but is an orthogonal problem).
Claiming that the observed effects can be explained by the rivers would imply that those river do not exist outside of the city...
The next version of Sherlock should be much more like Watson, i.e offer an Aqua interface to many web services. For this, a javascript engin will come in handy.
The interesting thing for me is that it shows a good trend, i.e that OS X is converging with other Unixes not only at low level (Jaguar should sync with a more recent version of BSD) but also at the component/framework level: beside this Javascript component, CUPS is scheduled to be included in Jaguar.
An interesting question would be, what other open source components/framework would be good additions to Mac OS X? I suppose one obvious answer is a native version of GTK
Also understand that many carbon applications have trouble coping with non-HFS+ file-systems. Here in the lab, I mount my solaris home directory thru NFS, and some carbon apps cannot start from my home directory because of this. Some carbon applications even have trouble with files in this file-system (on bad days Acrobat Reader tells me the file does not exist).
As applications and system frameworks become more file-system agnostic. I suspect Apple will probably put less emphasis on HFS+ and put more effort in other file-systems.
I agree that the main problem might well be the culture schock. In my experience, people from the US tend to underestimate this factor and have trouble adjusting to the way things work around here. Things are usually not better or worse than in the US, but simply different: paperwork, the way things are done, relationships between people, social customs, etc.
Also don't underestimate the paperwork - switzerland is a nation of bank and insurance companies. There is a lot of paperwork especially if you are a foreigner. And if you only speak english, it will be even slower.
Whenever you end up in the german speaking part or the french speaking part, you'll need to learn a local language. Many people, especially in cities like Zurich or Geneva know some english and many things are labelled in english nowadays. Still learning a local language helps for day to day life and socialising.
You can, to some extent, avoid this, especially in Geneva, where there is a large english speaking community. Some of those guys stayed for more than twenty years in Geneva and still don't know a word of french. Somehow I thing that by doing this, you miss something...
Please don't call people names.
Instead, read this page:
http://www-personal.umich.edu/~srb/openafs/
Also, large buildings are blown up all the time when they are demolished - albeit usually there are no people inside. But from the meteorological point of view, it proably makes little difference.
The port/implementation that is proposed is not of Cocoa, but of Carbon. Cocoa is the API that is inherited from Next, Carbon is the API inherited from the Macintosh Toolbox.
This implementation would not permit such things as Cocoa (or Carbon) versions of GNUCash. Instead this would mean that current carbon applications (Microsoft Office, Photoshop) could be compiled to run on a Linux like system.
Doing this would mainly require a lot of work., Carbon is quite a large API. Among the issues I see:
As for source compatbility, the design differences between linux and classic Mac systems is rougtly the same than the difference between Mac OS 9 and Mac OS X. Carbon was designed to be implemented on a Unix core. If the Carbon layer is correctly implemented then it should work.
I used to compile to dvi and then convert to Postscript because most of the figures I used were eps files. Most people in the lab are still working this way. When there are eps figures, xdvi basically call ghostview to convert the eps to a bitmap.
The advantages of compiling to pdf are numerous:
This is typical, many Apple docs were peppered with jokes. The examples for the GUI in the Inside Macintosh were about about SurfWriter, the coolest word processor (or something like that). Most glossaries had an (incomplete) entry for RTFM, etc...
Indeed, WebDAV is a good candidate - Apple is also supporting WebDAV strongly (an iDisk is simply a WebDAV share).
A long time ago, our school (the Swiss Federal Institute of Technology in Lausanne) built its own computer, it was called smacky...
Until the OS community is joined by skilled art people OS games will be limited.
Most food I ate in the military was officially considerd delicious (edible if you are hungry) or very good (tastes like dog food). If they told the press that the food is acceptable, I cannot fathom how disgusting this must be... shudder.
Photoshop does its own VM to handle the memory needed for the image. As far as I remember it needs four times as much disk space than the original picture (this is needed for things like filtering and undo).
I don't know of a cheaper alternative that would do the trick. If I had to write such an app, I would look into mechanisms to install a custom pager that would handle the image data - using the image file as backing store - this is basically what you describe (loading the parts that are needed), but integrated with the VM mechanism.
If the app needs some basic functionality like zooming, things are a little more tricky: lets say you want to dispay a 1/10 zoomed out version of the image, then you need to process the whole file to calculate the reduced image. As this is expensive, you would probably want to cache the result.
This could again be done using a custom pager, that simply clear the memory when the pages are swapped out, and regenerate the needed pages when the memory needs to be swapped in again.
Measuring the pulse rate is difficult, most cheapo wristwatches that do this are very unprecise and they are designed for oldies doing their jogging, not kids that play. I suspect the pulse rate of kid can skyrocket when it gets excited, also kids often gets a lot of minor wounds (a hard and bulky bracelet might in fact be a cause of injury) so the risk for false positives is very high. On the other hand, a kid can drown without any trace of blood.
Honnestly if you think that kids can be handled like cars, you never had to manage kids, and IMHO, you don't deserve to. The device you describe could signal that the wearer is dead. This might be very usefull for the military, but I would not consider it for parental help...
Also I fear that it will create a false sense of security for parents. This gizmo might work against people would kidnap kids (which is a rare event) but won't protect them from harm (which is much more probable).
The bottom line is were is the line between protection and overprotection. If I were worried about the safety of my child, I would first consider moving to a safer place, and not letting it alone.
I have no problem with a medic getting a phone-call in a cinema. The problem is, I can bet that 99% of the guys using portables loudly in public places do not fall into this category. On the other hand, I don't know if people who really can be called for an emergency actually rely on off-the shelf, civilian portable phones, when they are in public places, or is this a myth (I have no idea, just wondering).
The core issue, is of course, a social problem: keeping you phone on in a public place is impolite. Solving the problem in the social context basically fails because social pressure is low and important people can break such social rules.
Of course everybody is important. Medical people must be reachable, and firemen, and policemen, and the technician monitoring critical systems (most systems are critical in one way or another), and any mother or father with young children and the CEO of any company which might go enron, and his secretary, and their psychiatrist.
Heck if anybody is unimportant enough so that he does not to need to be reachable at any time, he probably cannot afford to got to the cinema...
Trying to solve a social problem with a technical solution generally fails. If such a bluetooth solution would be implemented, everybody would bypass it. The guy you think is a jerk thinks he is important.
A social and low-tech solution would be to use the jammer and require people that need to be reachable to give their gismo at the entrance. There, the device is monitored by some guy. If a signal arrives, the guy searches the person. This would solve the technical problem (getting the information) and the social problem (medics will not objet to this, jerks will).
One solution to this problem would be to filter postscript files by searching if they contain any color command (like setrgb, sethsb, colorimage). This solution is fast, but not very efficient: many postscript job contain headers that call the color operators, even if they are not needed (often they included by code that overloads such calls with a grayscale equivalent). Still this would be a first (fast) mean of finding black and white postscript filter.
A more complex, and more effective solution would be something like this.
- Convert each page of the job to a low resolution bitmap (this can be done using gs and postscript management scripts)
- For each bitmap page, check for colors (grascale pixel are R==G==B).
The problem of this approach is that it is quite expensive in terms of performance.Finnally, one trick that could work would be to add some functions in the postscript header. Basically, overload all color operators so that if they are called, they flag the current page (or better they check if the color or image they are passed is really color).
If the flag is present ignore the next showpage operator and flush the graphic state.
This way you can send the job to the black and white printer, and only the color pages will show. You send a slightly different version to the color printer, but in this case, you only print the flagged pages. Voilà
That said, make sure that the black and white and the color printer are somehow similar (same resolution) if not, the two sets of pages (color and black and white), will look to different.
Actually, there seem to be a variant of gcc that supports altivec